Whatever. I know I will not use WPF because WPF not multiplatform, and I am not interested in writing software that is hopelessly tied to the technology of a what is essentially a large competitor. Unless of course Microsoft decides to be charitable and donate the WPF source code to the Mono project.

Bass said:

Because they aren't really improving WinForms all that much (which might actually be a good thing). Depending on who you ask, people will often claim WinForms is an "obsolete" technology.

Whatever. I know I will not use WPF because WPF not multiplatform, and I am not interested in writing software that is hopelessly tied to the technology of a what is essentially a large competitor. Unless of course Microsoft decides to be charitable and donate the WPF source code to the Mono project.

If we let obsolescence and lack of support/updates put us off we'd be changing UI frameworks every couple of years!

Bass said:

Because they aren't really improving WinForms all that much (which might actually be a good thing). Depending on who you ask, people will often claim WinForms is an "obsolete" technology.

Whatever. I know I will not use WPF because WPF not multiplatform, and I am not interested in writing software that is hopelessly tied to the technology of a what is essentially a large competitor. Unless of course Microsoft decides to be charitable and donate the WPF source code to the Mono project.

Bass, as silverlight is going to have a linux version then the mono folks have the core / subset of WPF already...
given that I think that a version of WPF for Mono is very possible to see after they have the silverlight subset working.

not a for sure thing but see how that could happen?

as to the issue of beeing bound to a platform... well we could just write for telnet and curses and forget all the other stuff...

honestly I have never seen a really good way to write-once-run-everywhwere  it's been done to a degree but often results in stuff that looks wrong on some OS and always tends to make it more complex.

on one hand sticking to one "platform" does limit some things but it also has a benefit of once you know that set of apps, sevrvers and clients then you can focus on delivery.  when you try to make things work on multiple systems it does tend to make the development and the testing and the maint. and the setup and the support more complex and costly.

it's a trade off, not perfect....

Some folks go with LAMP, some with .Net .... each has it's place.

LeoDavidson said:

Bass said:

*snip*

If we let obsolescence and lack of support/updates put us off we'd be changing UI frameworks every couple of years!

The thing is, if someone tells you WinForms is obsolete, they are probably talking BS. Microsoft has never released a plan to cut support for WinForms. It will be supported in .NET 4.0, and for the forseeable future.

footballism just contributed a tidbit of knowledge regarding use of BindingListCollectionView in ViewModels to help with interop situations, ViewModels, and DataSets...

Other than this, WinForms is going the way of the DoDo bird, imho.

JohnAskew said:

With the adoption of WPF often coming as an interop -piece-by-piece- substitution across existing WinForms applications, this perspective would be a good one to focus upon. What are best practices for migrating a WinForms suite to WPF incrementally, mixed, interoperational?

footballism just contributed a tidbit of knowledge regarding use of BindingListCollectionView in ViewModels to help with interop situations, ViewModels, and DataSets...

Other than this, WinForms is going the way of the DoDo bird, imho.

-> What are best practices for migrating a WinForms suite to WPF incrementally, mixed, interoperational?

ElementHost and WindowsFormsHost are the things which you could plug into WPF visual tree or Windows Forms' hwnd parenting tree to enable Windows Forms & WPF interop, but there are many issues when mixing heterogeous content, such as airspace issue, focus interop issue, and Windows Forms/WPF message pump interop issue etc etc.

I've dealt with many such issues, so probably I just look at this from a very buggy mindset:)

Zhou Yong

harumscarum said:

Hey thanks I'll have to watch this. I work with software that we can integerate with asp.net, winform, ect. I always prefer to use winforms first because they are the easiest to work with. ASP.net to me after 1.1 seemed to be the most over engineered platform in .net.

->I always prefer to use winforms first because they are the easiest to work with. ASP.net to me after 1.1 seemed to be the most over engineered platform in .net.

Nope, from my personal experience, WCF is the most over-architectured, then comes CAS, then comes WPF, I never use Entity Framework, but lots of guy also complain about it too:

http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Zhou Yong

Bass said:

LeoDavidson said:

*snip*

The thing is, if someone tells you WinForms is obsolete, they are probably talking BS. Microsoft has never released a plan to cut support for WinForms. It will be supported in .NET 4.0, and for the forseeable future.

MS are good at keeping old/obsolete stuff working for a very long time, to their credit. I just wish they'd design and write a good UI framework and then stick with it for more than a few years at a time.

If WPF is finally that framework then great, but coming from a C++ background where we've had one neglected UI framework after another (and fairly limited design tools, code libraries and widgets), then seeing WinForms go the same way, and now reading various complaints* about WPF, I find it hard to get enthusiastic. All those C++ frameworks still work but they're also all still more or less dead (though MFC, the one which probably deserved to die the most, did get a surprise set of updates recently).

(*Other people's complaints. I haven't used WPF yet myself.)