R – Implement WinForms using WPF

netwinformswpf

This question is a result of a lunch-time conversation with a co-worker…I've read questions like WPF vs. Winforms…and I personally think that long term WPF is the way to go. The problem/question is what to do in the meantime.

Yes, WPF certainly has its advantages; not being built on GDI/USER is one of them. But at this point in time (i.e., late 2009; using VS2008 or perhaps even VS2005; Silverlight3 recently released and not yet widely adopted/deployed), WPF almost looks like it might be an "over engineered" solution. While I'm sure that will change with time, it doesn't make things any easier today, nor for the immediate (say <36 mo) future.

And let's face it, WinForms is really simple and easy; especially for the many co-workers who are still "happily" using MFC. Yes, it may be difficult to do slick animation, 3D graphics, gradients, etc.; but it's a very utilitarian solution that a lot of people (i.e., C++/MFC developers) readily understand today.

With that longish introduction–has anybody thought/tired/etc. about the idea of implementing (most of) WinForms using WPF (i.e., WinForms sans GDI/USER)? I'm sure given things like Control.Handle, 100% re-implementation isn't possible. But it certainly seems like many WinForms controls could be re-implemented using WPF "under the hood". Or is this really border-line impossible?

By "re-implement", I envision removing assembly references to System.Windows.Forms replacing them with (say) Microsoft.Wpf.WinForms and then rebuilding my application. After that I would expect to fix some (relatively small number of) compiler and/or runtime errors (say P/Invokes to Win32 APIs).

Something like this seems like a nice complement to Microsoft's various WinForms/WPF interop strategies such as WindowsFormsHost. For example, developers could start to use/learn WPF in a much more incremental fashion.

Edit: While the various "why?" discussions are interesting, they don't answer the basic technical question: "yes., ..here's how….; or no, …because…".

Best Answer

Honestly, I think you could probably implement a layer to allow you to port most of WinForms to WPF, but you really shouldn't. Let me use an analogy - Moving from WinForms to WPF is like moving from an imperative language to an object oriented one (or from OO to pure functional). It's really hard, nothing seems to work right, solutions don't make sense, everything seems over-engineered, and then... you get it. You have a flash of insight, the light bulb goes on and you see a whole new world where tasks are easier to accomplish and easier to maintain (than in WinForms).

But first you have to grok it. It's really easy to keep coding in the WinForms style in WPF so you have to force yourself not to or you'll never take that next step. Force yourself to start from a clean slate, learn how to apply MVVM, take a look at Prism, build some really simple apps and then add to them to explore how to manage complexity the WPF way. You might implement WinForms in WPF but all you would ever have is people coding WinForms in WPF. You basically end up with the equivalent of (from the Imperative -> OO days) making every class a singleton with all static methods. You might be "using" WPF, but you (and/or your coworkers) will never grow past that stage.

From what I can glean from your situation I would recommend that you not try to switch to WPF unless you are writing a new application with a small team. If that does end up being the case then the small team can be a nucleus for change because once one person in your organization "gets it" they will teach others near them until the light bulbs start turning on all around over the place. That's what we've done in my current organization and looking back the progress everyone's made just in the last 6 months is staggering.