Windows Forms vs WPF

The following short piece is about my opinion of comparing old fashioned Windows Forms development to using WPF (Windows Presentation Foundation).

After some real experimenting, researching, googling, scratching, digging, hair pulling (what is left of it), swearing, yelling, kicking around getting a very simple WPF application to work I can seriously say that WPF is a load of … brown stuff. I’m not denying that it could be used to create really beautiful and powerful applications given enough time, patience (and hair) but, the effort to do this is making me question whether this is worth while. It has a few benefits over WinForms but they are offset by some really annoying and lacking features, not to mention that it also have all the same disadvantages that WinForm applications have (compare to stuff like Web/mobile applications). Essentially, anything you can do with WPF can also be done with WinForms with less time and effort.

Let me give a few examples.

Basic layout and design of a form

I’m sure once you are completely fluent with WPF and all the possible permutations of properties, behavior, styles etc. that you can also do basic layouts of an application very quickly. For me, knowing exactly what I wanted and even what I’m looking for, it took more that two days to create a basic interface (which I could have done in 5 minutes in WinForms). Yes, part of the problem was I’m not fluent in all that is WPF but thanks to Google I could find solution quickly every time. Despite this I had to retest every possible basic behavior of all controls – even simple things like clicking on a blank space inside a control to ensure all ‘basic’ functionality as a plain user would expect (people that have been using Windows app for years), are still the same. One of the most important fundamental concepts of UI design is to have consistency – like behavior of controls. Something like keyboard navigation was seriously not part of the WPF designers ideas.

The ListView control.

This control has been changed in several ways which could both be seen and good and bad. In WinForms this is/was one of my favorites. The way you design, code and use columns are very different from WinForm ListViews. It does give you more powerful ‘formatting’ options but this make it incredibly complex as well. Doing basic stuff like right aligning a column is not straight forward anymore. Yes, it can be done but this requires doing ‘non-standard’ things like ‘Styles’, custom code and so on. Then behavior like selecting items in the ListView has changed and even something like ‘unselecting’ all items by clicking on a blank space inside the control now requires you to write ‘extra’ code just to accomplish it. Essentially this is not the same ListView control that we were used to in WinForms but a new control that superficially looks like it.

There is however one aspect/feature of this control that I really like. The way you can bind columns to properties of an object – which by the way is the only way to use it! In general I do NOT use databinding features because it removes your ability to do really powerful things with the control and more importantly databinding controls never really work well with huge sets of data. For that reason I always populated my controls myself so I have ‘real’ control over them. That does come at the cost of having to manually always sync the displayed values on a control with the underlying data.


There might be people out there that prefer WPF over an ‘old’ technology like WinForms and possible they can create even better applications if they put their mind to it but I’m still in the WinForms camp. Then you have to keep in mind that WPF just like WinForms as a development technology is in danger of being abandoned thanks to the whole HTML5 and JavaScript mobile revolution.  WPF might become just another one of those potential (good) technologies that Microsoft killed before it had time to evolved into something really good. That is a shame.


I also discovered that WPF does not even support some VERY basic dialog boxes like browsing for a folder. I mean, FFS Microsoft, what were the developers of WPF smoking when they created this abortion of a tool/technology??

Also, they changed the very standard way of returning results from dialog/messages boxes to use a nullable boolean in stead of a usable structure. WTF??

  1. I’m sorry but you really failed on this one.

    Let me split this into parts:

    1 – anything you can do with WPF can also be done with WinForms with less time and effort.

    Wrong, winforms is a useless dinosaur, it does not use hardware acceleration, it does not have built in UI virtualization, and it doesn’t allow customization of anything without resorting to a bunch of horrible hacks such as “owner draw”, and even with that it doesn’t allow rich content.

    If you seriously believe that “anything you can do with WPF can also be done with WinForms” please go ahead and show me your winforms version of this:

    2 – Basic layout and design of a form

    WPF, in contrast to dinosaur winforms, is resolution independent by nature. It allows you to define layouts which easily adjust to any screen solution and window size and DPI settings. winforms forces you either support only 1 resolution, or to resort to all sorts of horrible hacks in order to adjust the UI elements’ sizes manually.

    The problem is that you surely attempted to use a winforms approach by dragging and dropping in the Visual Studio designer, instead of writing XAML manually as any WPF professional developer would.

    No, definitely WPF is not suitable for drag and droppers or casual developers who have no idea about patterns such as MVC or MVVM and expect to do everything in Form1.cs in code behind. It’s targetted to highly skilled developers who can deal with XAML, development patterns and advanced programming constructs and concepts.

    3 – even simple things like clicking on a blank space inside a control to ensure all ‘basic’ functionality as a plain user would expect.

    WPF has advanced hit testing functionalities, and also has built-in support for transparency at all layers and levels of the UI. This is really different from winforms, which of course doesn’t support anything and is horrible.

    However, most of the default styles and templates for all WPF controls (which are loaded at runtime depending on the Windows Theme settings such as Aero, Classic and whatnot) have opaque backgrounds and therefore don’t have any Hit testing issues. You probably incurred in an alignment error where some of your UI elements were not stretched to their container and therefore hit testing didn’t work in the empty space. That is obvious, clicking on empty space in the screen will do nothing.

    4 – ListView: ‘non-standard’ things like ‘Styles’. Wrong. Styles and Templates are part of the standard WPF features that any WPF developer uses on a daily basis. Of course these might seem extraneous to you, because winforms doesn’t have any of that, but again, approaching WPF with a winforms mentality is a mistake.

    “Essentially this is not the same ListView control that we were used to in WinForms”, no of course not. winforms doesn’t support anything, it’s a dinosaur that forces you to only use the default, ugly stuff and not being able to customize anything.

    5 – “In general I do NOT use databinding features because it removes your ability to do really powerful things” – Wrong. WPF’s data binding is really powerful (as opposed to winforms’ databinding which is a ridiculous joke), and YES it allows you to do really powerful things. In fact, There are many complex things in WPF that are much more easily achieved via DataBinding than thru a procedural approach.

    6 – “databinding controls never really work well with huge sets of data” – Wrong. As mentioned above, WPF has built-in UI virtualization and it supports huge sets of data (actually it doesn’t even care about the size of the data because it only renders what’s visible on screen), therefore you might bind a collection of 2 million items and WPF will react exactly the same as if it were 20 items.

    7 – “WPF just like WinForms as a development technology is in danger of being abandoned” – Wrong. Microsoft’s most recent UI framework (WinRT XAML) that shipped with Windows 8 shares all the same concepts (styles, templates, databinding, triggers, ItemsControls, etc), uses the same language (XAML) and supports the same development pattern (MVVM) as WPF. This means that existing WPF code and skills may eventually be carried over to the WinRT XAML framework.

    In contrast, all the horrible hacks you are used to in dinosaur winforms are completely useless in present / future technologies because new technologies are not similar to winforms in any way. Clearly winforms is a worthless dinosaur and no one cares about it anymore.

    • Thanks for your input. You have a few good points but you also make a few assumptions which does not apply to all cases. Also, dinosaurs are way cool as long as you stay away from the sharp teeth.

  2. You’re welcome. Can you name my assumptions? and how these don’t apply to which cases? You also made the initial assumption that you could get into WPF with a winforms mentality. That’s why I took the time to give a detail, techical-fact-based response.

Leave a Reply

%d bloggers like this: