Implement WinForms using WPF?

Question

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...".

Answer 1

A thing called the WindowsFormsHost can help out with moving controls over initially. However, I've found it to be pretty slow. You're much better off spending the time to learn WPF and write everything from scratch and take advantage of the features, especially data binding!

Answer 2

First off, WPF isn't "over engineered". I would say it is just perfectly engineered, as it is an extremely complex endevor to implement a UI framework that supports rich composability, rich databinding, 2D and 3D in a single platform.

WPF has a slight learning curve, but it isn't very steep, and occurs in stages. Give yourself 2 days with it, and you will NEVER look back. WinForms is easy for easy things. WPF is easy for just about anything, and the capabilities you have via its extensive composability and databinding will put WinForms to shame for anything more complex than your most basic app.

As for WinForms controls being reimplemented...there is little need. A lot of the highly complex WinForms controls that are available from third parties are only required because of how difficult it is to customize the UI of any WinForms control. With WPF, enhancing any OOB control is easy, and nearly limitless.

I highly recommend WPF as the UI platform of choice, unless your target hardware is incapable of rendering WPF.

Answer 3

I'm not really sure I understand your question - it is already possible to use WPF libraries in a Winforms like fashion (assemble everything in code with no XAML), and most of the common Winforms controls have their direct WPF analogs.

The real question is why would you want to? Many of the big challenges of developing Winform applications are easily solved with WPF databinding and templating techniques.

And I'm not even talking about fancy visual effects, which just take waaaaaaaay too much work in winforms, but simply something like visualizing a list of arbitrary items in a collection.

Furthermore, if you assemble everything in code Winforms style you don't get the design time editing support.

Answer 4

You really must look at it from the long term perspective of the life of the application you are creating. While WPF might not be as mature as Windows Forms, it allows a programmer to separate design (XAML) and logic (C#/VB). I do not believe it would be good if you create your controls in WPF in a Windows Forms style. Imagine placing it all back in XAML for some reason in the future!

That being said, if you really wish to bring some Windows Forms' controls into WPF it is entirely possible. You simply need to add a reference to WindowsFormsIntegration, add the appropriate namespaces for it in your code and a add a WindowsFormsHost tag in your XAML. In my opinion, using this should only be temporary (it is rather slow for the moment). On the other hand, future frameworks will most likely make WPF a lot better (having 4.0 in my mind).

Learning WPF now is probably the best thing you can do. Getting to know your way around and using the WPF Toolkit for certain missing controls from Windows Forms can be a bit time consuming at first since there are some things that are different from Windows Forms (control customizing and data binding comes to mind).

If you keep on using Windows Forms you will be missing out on new features in WPF that make development faster. For example, you can have people working on the design while others work on the logic side of the application because of the more pronounced separation of design and logic.

Answer 5

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.

Answer 6

An analogy for your coworkers:

Which is better, the automobile or the horse and buggy?

1. Automobiles are not as mature a technology as the horse and buggy. Horse and buggy has been around over 2000 years, automobiles less than 200.

2. Automobiles are overly engineered and extremely complex. Horse and buggy is simple.

3. People in many parts of the world don't know how to drive an automobile but have good skills with the horse and buggy.

Question: Can we simplify our automobiles so they are controlled by reins, eat hay, and be repaired by veterinarians and carriage-makers?

My point here is that WPF is a very mature technology by now, much more powerful and easy to use than WinForms, and isn't at all difficult to learn. It should be the vehicle of choice except for "country drives" and other specialized purposes.

I agree with the others that it is trivial to use WPF in a WinForms-like manner so there need be no significant learning curve if you want to use it that way, but it is wasteful not to take advantage of the new paradigms.

I disagree that you should delay implementing WPF in your main application. It's very easy and painless to mix WinForms and WPF content in a single application. I recommend building new pieces in WPF and leaving old pieces in WinForms until there is a need to touch something. Even if your existing application is native C++, it is still easy to use WPF with it as long as the data is easily accessible from managed code.