> From this article about the latest version of Visual Studio:
> http://www.betanews.com/article/Visual-Studio-2010-Beta-1-NET-4-Beta-1-for-general-release-Wednesday/1242660335
>
> ===============
> ...Soon after the preview edition was released, the company revealed that it
> was scrapping that more traditional front end in favor of a design based on
> the Windows Presentation Foundation platform.
> That design made its way to select testers first, who we've learned did not
> like one of the new design changes: the use of different pointing triangles
> to denote collapsed and expanded code section blocks. As Visual Studio
> General Manager Jason Zander blogged last week, the feedback essentially
> boiled down to, why change a good thing? So the [+] and [-] boxes from VS
> 2008 have returned in Beta 1.
> ===============
>
> Why change a good thing indeed.

| > It's also an indication that the writing is on the wall for WinForms
| > applications. In other words, if you did jump from VB6 to VB.NET, your
| > early .NET desktop code is in danger of being declared obsolete... And
| > there's very little support for upgrading WinForms code to WPF (from a
| > quick Google search).
| >
| > Will it ever stop??
|
| Were did you come up with that idea?  WinForms is still supported - but
WPF is
| better, and probably should be used for new applications going forward.
Nice
| thing is that you can mix and match wpf and winforms fairly seemlessly -
| even on the same form.
|
| --
| Tom Shelton

> Here is Microsoft policy regarding deprecating language features. To see it,
> download the following file, and see section 1.2.
>
> http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=39de1dd0-f775-40bf-a191-09f5a95ef500
>
> Quote:
>
> 1.2.3 Language deprecation
>
> Over time, parts of the language or compiler may become deprecated. As
> discussed previously, it is not acceptable to break compatibility to remove
> such deprecated features. Instead, the following steps must be followed:
>
> * Given a feature that exists in version A of Visual Studio, feedback must
> be solicited from the user community on deprecation of the feature and full
> notice given before any final deprecation decision is made. The deprecation
> process may be reversed or abandoned at any point based on user community
> feedback.
>
> * A full version (i.e. not a point release) B of Visual Studio must be
> released with compiler warnings that warn of deprecated usage. The warnings
> must be on by default and can be turned off. The deprecations must be
> clearly documented in the product documentation and on the web.
>
> * A full version C of Visual Studio must be released with compiler warnings
> that cannot be turned off.
>
> * A full version D of Visual Studio must subsequently be released with the
> deprecated compiler warnings converted into compiler errors. The release of
> D must occur after the end of the Mainstream Support Phase (5 years as of
> this writing) of release A.
>
> * Finally, a version E of Visual Studio may be released that removes the
> compiler errors.
>
> Changes that cannot be handled within this deprecation framework will not be
> allowed.

"Karl E. Peterson" <k***@exmvps.org> wrote in message
news:O$l3jTm3JHA.6004@TK2MSFTNGP02.phx.gbl...
> Nobody wrote:
>> Here is Microsoft policy regarding deprecating language features. To see
>> it,
>> download the following file, and see section 1.2.
>>
>> http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=39de1dd0-f775-40bf-a191-09f5a95ef500
>>
>> Quote:
>>
>> 1.2.3 Language deprecation
>>
>> Over time, parts of the language or compiler may become deprecated. As
>> discussed previously, it is not acceptable to break compatibility to
>> remove
>> such deprecated features. Instead, the following steps must be followed:
>>
>> * Given a feature that exists in version A of Visual Studio, feedback
>> must
>> be solicited from the user community on deprecation of the feature and
>> full
>> notice given before any final deprecation decision is made. The
>> deprecation
>> process may be reversed or abandoned at any point based on user community
>> feedback.
>>
>> * A full version (i.e. not a point release) B of Visual Studio must be
>> released with compiler warnings that warn of deprecated usage. The
>> warnings
>> must be on by default and can be turned off. The deprecations must be
>> clearly documented in the product documentation and on the web.
>>
>> * A full version C of Visual Studio must be released with compiler
>> warnings
>> that cannot be turned off.
>>
>> * A full version D of Visual Studio must subsequently be released with
>> the
>> deprecated compiler warnings converted into compiler errors. The release
>> of
>> D must occur after the end of the Mainstream Support Phase (5 years as of
>> this writing) of release A.
>>
>> * Finally, a version E of Visual Studio may be released that removes the
>> compiler errors.
>>
>> Changes that cannot be handled within this deprecation framework will not
>> be
>> allowed.
>
> Well, I guess if they're actually living by that nowadays, I can feel that
> "with a little help from my friends" we actually accomplished *something*
> along the way.

"Karl E. Peterson" <k***@exmvps.org> wrote in message
news:eYyoq$v3JHA.4412@TK2MSFTNGP06.phx.gbl...
> Dan Barclay wrote:
>>>> Changes that cannot be handled within this deprecation framework will
>>>> not
>>>> be allowed.
>>>
>>> Well, I guess if they're actually living by that nowadays, I can feel
>>> that
>>> "with a little help from my friends" we actually accomplished
>>> *something*
>>> along the way.
>>
>> BWAHAHAhahaha.  So you think maybe, somehow, they will follow that sort
>> of
>> guideline?  Maybe like they followed the (fairly good) guidelines for
>> language changes they <cough> followed for VB7?
>
> Yeah, sorry, was very tired when I wrote that.  I have no doubt they'd
> ignore this one just like they ignored the last one, should it prove more
> convenient for them.
>
>> This will be forgotten/ignored within two years.  Those who agreed to it
>> will be moved/gone and whoever replaces them will make their own call on
>> it.
>
> Total lack of institutional memory.  That's MSFTs main problem.
>
>>> Too bad they couldn't have done this with VB6.  None of the current
>>> animosity would exist, and the community could've stayed intact.
>>
>> Too bad, yup.  It wasn't just VB6 though, it was/is a culture that
>> started,
>> as well as I can figure it, shortly before or after VB1 was released.
>> They
>> did a pretty decent job until then, and since then a pretty poor job.
>
> They went and got all GUI on us, you're saying? <g>