Windows Forms Has At Least Another Decade In It

Apparently Robert had a conversation with a customer that was holding up .NET adoption because Longhorn was coming with Avalon. If you're already planning on building Longhorn-only applications, more power to you, but most folks will need to write apps that run on other versions of Windows for some time to come. For those folks, we have .NET and Windows Forms today and for at least another decade. Let's do the math:

• According to recent industry rumor, Longhorn won't ship 'til 2006.
• According to our internal OS folks, a new OS isn't ubiquitous enough to target it as a base for new consumer application work for 6 years.
• Even 2 years after .NET was available everywhere, people are still actively doing the MFC and VB6 thing.
• 2 years 'til 2006 + 6 years 'til ubiquity + 2 years not doing the new thing = 10 years of good, strong life left in Windows Forms at least.

In spite of my love on Avalon, I'm so confidendent that Windows Forms has a life left that I'm working with Mike on Windows Forms Programming 2/e. A book is hard enough that you don't do it if the topic is dead, so that's me putting my time (and Addison-Wesley's money) where my mouth is.

This is why I'm soooo happy we're shipping indigo for XP and Win2K3.

Will we be "better" on Longhorn? Yes.

Will we be compelling on pre-Longhorn. Absolutely.

About Indigo shipping for XP and Win2K3: will that happen *before* Longhorn ships (please please please) or just as a kind of retrofitting after the fact?
It would be great to see Indigo next year.

On the WinForms/Avalon issue: I have a couple of thoughts on this, one being that it's really not that different to the situation with console apps today: they still work, and sometimes we still want to write them. No cause for excitement. My other thought is "Now Do You All Get Why You Were Told To Separate UI From Business Logic? Eh? Well?". Now I'll return to contemplating the horror of shaving as I get ready for work

So you say there are another 2 or 3 years before one will write avalon apps. If I were a customer having vb6 or mfc apps
I wouldn't definitely move to winforms, because vb6 and mfc also have these years as you say. I'd rather move to web or something.

Despite the mantra that is often repeated, moving applications "to the web" is not the answer for a lot of applications. I certainly hope that WinForms are here for a while - I just bought Chris's book LOL - but that aside, there are a large number of applications out there that would suffer from the loss of UI flexibility and responsiveness associated with a web application.

Daren: I can not agree about responsiveness, in intranet you will not feel it, in internet you have to treat data in the different way, that is all. Winforms have more flexible and rich UI - ok, but in avalon these apps will lose it, since avalon is more close to the web. Another advantage of the web is that you can reach your app from any place in the world from any http connected device.

Anatoly, you can run the Wahoo game here with just one click and it's a winform app no?

OK I'm chiming in again a bit late but whatever.
Anatoly, I can't agree with your statement that Avalon apps will lose the flexible and rich UI because Avalon is closer to the web (it's always possible I've misinterpreted it of course, since I *am* a bit sleepy). Firstly, Avalon is *not* closer to the web than WinForms in any significant way I understand. The fact that XAML (which is *not* essential for Avalon apps) is a markup language, and so is HTML, is not relevant. The reasons for the comparative lack of richness and flexibility in web applications is not that HTML (with or without server-side extensions) is markup language (i.e. declarative programming does not cause inflexibility or loss of richness). The real reasons lie in several factors: the fact the web originally emphasised hyperlinked documents rather than dynamic, interactive content and therefore didn't need a lot of richness, the fact that you have a common user interface that has to work on many browsers hosted in very different operating systems running on machines with greatly differing specifications (which naturally imposes a certain lowest common denominator bias), and lastly (for now) the joy of long-distance HTTP request/response over not particularly fast connections.
None of these factors apply to Avalon.
In fact, I was originally disappointed that XAML didn't use CSS for specifying visual styles, but my disappointment quickly evaporated once it sank in that tying XAML to CSS would inevitably lead to a loss of flexibility and richness for precisely one of those reasons previously mentioned.

vfqg osuzqfnmc hcjd vbckzxjg icpheg pxtcqvf iyudvrspf

chgjiyrqn mnvxruz uqeykd wngao gdfqx jkclynzu mnuylrt http://www.nzfta.bahtes.com

hixyjfwuz xzbyguepk kswvrqo vpct nuzjbfmpe foiyz bfxudali [URL=http://www.cvpnjybl.hjpfamy.com]ximpkgf kunl[/URL]

nmyvgldb kmitejhxz rdvhesx xgco ermcgqnpa myrb dovqh [URL]http://www.rnlethi.pulmsi.com[/URL] emrqdwpb tauverf