It is time to write the GUI for my project, and I am wondering what technology to use. I did most of my .NET GUI development in .NET 1 & 2, so I know Windows Forms reasonably well. I am vaguely aware of WPF, but not yet attempted to “get into it”.
Are Windows Forms dead or dying? Is WPF a good technology to learn? Is it the future, just a phase, or a technology that can walk hand-in-hand alongside Windows Forms?
Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?
No. It is not significantly developed further (i.e. no new major additions), but it is fully supported in .NET 4, for example.
Yes.
It is intended that you eventually move over to WPF, but it is also understood that there are large existing codebases written in WinForms, and there’s no business case for rewriting them in WPF. Hence WinForms remains supported.
Broadly speaking, WPF is much more expressive. If you look at frameworks as set of Lego bricks that can be put together in various ways, WinForms bricks are much larger – each one does a lot – and therefore there are fewer ways to put them all together. Quite often, when you need something-but-not-quite like what an existing brick does, you have to write your own from scratch. In WPF, the bricks are significantly smaller, and can be combined in many interesting and even surprising ways.
For a concrete example, consider how WPF
Buttonis a container that can host arbitrary content – not just image+text as in WinForms, but absolutely any other WPF control or set of controls.WPF is also much easier to write dynamic layouts in compared to WinForms. The latter has layouts, too, but the problem is that they’re a royal PITA to work with in visual designer, and writing WinForms component initialization by code is very tedious. With WPF, you just write XAML markup by hand, and layouts (and control trees in general) are very naturally represented in XML.
Partially stemming from the above, I find that WPF is easier to localize. For one thing, it’s because you really do need dynamic layouts for localizability (since you don’t know in advance the length of the strings in all locales). WinForms solution to this is to consider not only text labels, but also control position and size, as “localizable property” – so the translator is supposed to rearrange controls on the form himself if he finds that strings don’t fit. In WPF, dynamic layouts are the default approach, so localizer just deals with strings.
WPF binding framework is rather powerful (even if verbose, thanks to lack of inline converters), and heavily promotes MVP, and, in general, model/view separation. This is possible to achieve with WinForms in 2.0+, and I try to do that there as well, but it’s more tedious, especially with respect to null handling, and sometimes can be rather buggy.
One particular pain point is the way WinForms designer interacts with source control. There are two similar problems here. First of all, designer serializes edited form as code, and sometimes very minor changes in layout can make the designer generate completely different code (this is particularly noticeable if you edit toolbars) because it shuffles the code lines around – i.e. in reality it changed a single property value on one line, but it also reordered everything. This leads to very much noise in history (it’s nigh impossible to tell what exactly was changed when looking at diffs), but more importantly, it means that merging such files is a major headache. This usually happens when two people work with the same form at the same time, and then one commits his changes, and the other one tries to commit, finds out that the file was changed in the meantime, tries to merge, sees the diffs, and jumps out of the nearest window.
A very similar problem happens when you use WinForms localizable forms, which pushes some properties to a resource file. Again, the designer very much likes to reorder property values in resource file for any trivial change, with all the same problems as described earlier.
Now as to deficiencies in WPF. A major one is that it’s quite a bit more complicated, and may feel unfamiliar to someone with experience only with WinForms, VCL, VB, or other similar “traditional” frameworks. Another problem is that documentation, in my opinion, is not perfect – it usually gives a decent overview, but rarely covers corner cases, some of which can be pretty important. This is the case for WinForms, too, but there are fewer possible combinations there, so fewer corner cases as well.
There’s also the issue of third-party components. WinForms had been around for a long time now, and there are plenty of those available for it, and a lot of them are very mature. WPF is comparatively young and still going through growth pains, and so do most third-party solutions for it.
One particular pet peeve of mine in WPF is the way it antialiases text – which is perceived as being of much worse quality compared to plain Windows ClearType by most people, especially on small font sizes; see this bug report for more info. This is fixed in WPF 4, but that isn’t released yet, and even when it will be, chances are that you’ll want to stick with the tried and true 3.5 SP1 for some time; and the fix isn’t backported.