Migrating from Windows Forms to WPF... was it worth it?

Question

I also have a desktop application written in Windows Forms that is a middling size (a couple dozen major forms backed by 46 tables in the database). I'm thinking about rewriting the UI in WPF, but before I go there I was curious if there were any war stories about doing such a conversion.

I use LLBLGen to generate my low level data access objects, and I have a business logic layer above that. The forms are databound to the business logic objects, although the main form uses caching objects to minimize round trips on the more common navigation routes. The UI never speaks directly to the database: always through the UI -> business logic -> low level -> datastore path.

One control that I use heavily is the TreeView, which acts as a visual guide and short range navigation tool. The tree has been heavily customized with icons, highlight colors and it is the control I worry most about porting.

Is there a story that might convince me to go ahead and convert (or conversely, wait until Microsoft is closer to pulling the rug out from under Windows Forms)?

EDIT: I was asked in a comment what motivation for conversion I have. I have some concern about future proofing: I have 500,000 lines of code that were originally ASP and VBScript. We have been porting the functionality over time to ASP.NET and C#, but only as we make changes to the code. The upside is we have kept costs minimized, the downside is half the code remains ASP and VBScript. I'm concerned about a similar situation arising with Windows Forms applications.

Am I worried today about Windows Forms going away? Not even close to it... but the application is moving from ASP and VBScript to ASP.NET and C#, has nine years of history behind it, and probably won't be replaced this decade (instead, simply it will evolve). The desktop application is likewise a long term project with years of history.

Answer 1

For me, the WinForms vs. WPF decision is a simple one - if normal people are going to use it, the user interface can make the difference between a winner and a loser.

It is definitely a steep learning curve. But I have NEVER gotten done with a nice looking WPF application and said "Man, I should have used WinForms".

I'd say invest in the effort to make your UI better whenever possible for your customers, so yes to WPF if that's the case.

Answer 2

WPF has a ridiculously large learning curve. It will most likely require you to rewrite a lot more than you think for just changing the UI. Also, a lot of features that would make WPF nicer to use just aren't implemented or included in WPF yet. Unlike routeNpingme, I have written nice looking WPF applications and have said, "What a waste of time, I should have used Windows Forms and completed in 70% less time".

EDIT: Also, unless Microsoft figures out a way to make WPF easier to learn, I don't see it catching on to the masses at all. WPF can do some very cool things, but a little effort to make it easy to understand instead of throwing stuff over the wall would have gone a long way. It would not surprise me in the slightest to see Microsoft drop WPF for something easier to work with in the not too distant future. So don't go changing your Windows Forms application just for the sake of changing it.

Answer 3

Pros:

• Ridiculously easy data-binding (most of the time)
• Ridiculously easy customization of look and feel

Cons:

• Very steep learning curve
• Some obvious bugs or issues. Similar to .NET 1.0 Windows Forms
• Little or no tool support

In my opinion, WPF will definitely replace Windows Forms at some point. However, right now the tools are the main thing keeping it back. I disagree with Dunk that Microsoft will drop it for something else. Change it yes, but I think it's here to stay.

Should you change your application to use WPF now? No. Feel free to learn WPF but if your application works fine currently, then WPF won't give you anything extra. It just makes doing what is possible in Windows Forms much easier.

Answer 4

WPF is great. It is particularly good for extending controls like TreeView with customisations. You can add a string as an item in a TreeControl. You can also add a small panel containing an image and some text in various fonts and colours. Or you can add buttons, or anything you like. It has a completely general composability system. Same goes for ListBox, ComboBox, Button, etc. All their content or child items can be as simple as a string or as complex as a multipage document viewer with zoom buttons (if you want).

But the only way to find out is to try porting one of your forms. It shouldn't be too hard to make a WPF Window open from within your existing app. I started using WPF by making new GUI panels that were hosted inside a C++ Win32 application. Eventually it was so obvious that WPF was the way to go that we switched it around and made the outer shell WPF, with some ancient dialog boxes still implemented by the old C++ code where we couldn't be bothered to rewrite them (probably exactly what will happen with Visual Studio 2010).

Answer 5

Porting is a tough decision. So just some thoughts to help you decide.

WinForms is OK while you work by the rules and keep everything drawn as is. But even redrawing a border on some controls may require complex and precise work and skill, as you already know from tree customization. The same tasks can be done in a very elegant way in WPF.

Also, the data-binding in WPF saves me a lot of time. In the long term, you end up thinking about data-binding scenarios that could not be remotely possible in WinForms without special-case coding.

I do not even consider WinForms for new development -- there is no excuse for customization costs.

Answer 6

I have started introducing WPF elements within my WinForms application and so far have had a lot of success.

The application's main component is a grid control and I haven't yet found the text rendering of WPF sharp enough to present a table of important textual data.

But the application has several additional panels, and the majority of these are implemented using WPF. So, I'm going for a hybrid of WinForms and WPF via the ElementHost control.

I have found the flexibility of WPF to allow for a much more attractive and usable UI, and my users seem very happy with it. In my case, it's also been politically easier to introduce WPF one panel at a time.

Answer 7

WPF's main value to me is in the binding, not in the cooler UI. The worst WPF I've ever seen is when people use WPF just because it's newer, and put all the work in the code-behind, including not using binding. What you get is WinForms data management. So be sure you're going to use the wonderful binding when you do WPF.

I would port the OP's business logic to a business layer for ease of maintenance and conversion. I wouldn't port the WinForms to Xaml at all unless new Xaml functionality was needed, and preferably not until after the functionality was ported.