WPF not Windows Forms gets the Windows 7 love

Microsoft’s Scott Guthrie has a blog post today about what’s new in Windows Presentation Foundation 4, and one of the things he mentions is Windows 7 multitouch support – as also described in this walkthrough – and integration with the Windows 7 taskbar, jump lists, icon overlays and so on. Taskbar support is wrapped in the System.Windows.Shell namespace in PresentationFramework.dll.

This means that Microsoft is making it easy for .NET developers to support Windows 7 in WPF applications. However it is not extending the same love to developers using Windows Forms, the older GUI framework. That said, there is always the Windows API Code Pack which covers many Windows 7 features including the taskbar and jump lists, or you can do your own COM and native code interop. No doubt with a bit of effort all the features can be be integrated into a Windows Forms application.

Still, there’s no doubt that Microsoft is now steering us towards WPF rather than Windows Forms for new desktop development. About time, you may say, considering that WPF first arrived in 2006. While that’s true, there have been good reasons to be cautious about adoption. WPF apps use more resources than Windows Forms applications, require the .NET Framework 3.0 or higher, and for a long time were talked down even by Microsoft as unsuitable for line of business applications.

That tune has now changed, though when you consider the large numbers of existing Windows Forms applications, and the fact that developers contemplating radical revisions or new projects may well be looking at web or rich internet clients, WPF is still something of a hard sell.

On the other hand, the improvements Guthrie describes are significant, not only for Windows 7 features, but also key areas like cached composition for graphics, which can greatly improve performance, and a new text rendering API.

It’s also worth noting that Windows Forms was never a great framework. It wraps the old Windows GUI API which makes resizable layouts and scaling for different display resolutions difficult, as well as lacking all the multimedia and effects goodness in WPF. Another factor is that WPF is designer friendly, with its own Expression Blend design tool. Windows Forms has nothing like that.

WPF has a family connection to Silverlight, which was originally called WPF Everywhere. Microsoft’s idea is that we code in WPF for the desktop, and transition to Silverlight for applications that require broad reach. So far though, mass migration to WPF has not happened, and Silverlight has an independent life as a platform for browser-hosted .NET applications that work cross-platform. Developers have many other choices for broad reach applications, including HTML and JavaScript, Java, and Adobe Flash.

Is it possible that broad adoption for Windows 7 could see renewed interest in WPF and Windows development? I think it will happen to a limited degree, but will not really disrupt the underlying trend towards web and cross-platform.

6 thoughts on “WPF not Windows Forms gets the Windows 7 love”

  1. To be honest, I think part of it has to do with Microsoft actually using WPF in a major product for the first time. People have been complaining about “fuzzy WPF text” since its inception, but Microsoft builds Visual Studio on WPF and the text problem is suddenly fixed? Mmhmm. I’m wearing my skeptical hat.

    Also, WPF is radically different from the old days. I have found, personally, that I (a developer) can create a passably appealing LOB application in Windows Forms, but I create a hideous mess in WPF without the help of a graphics designer. And the WPF designer tools are simply not there unless you have an MSDN subscription and have access to Blend. For the two-man team working in IT departments of companies whose primary focus isn’t software, WPF is a hard sell. For software houses like Intuit or Microsoft, however, it makes the nonsense of creating skinned, custom UIs much, much easier.

    Windows Forms was never great, but it was adopted quickly because it was based on a mature technology and it sure beat the heck out of dealing with the mature technology directly. It was a convenience layer, not a whole new stack.

    I feel that there is a bizarre split in graphics technologies on Windows now. Windows Forms was at least not a radical shift because it was based on the GDI and Win32 controls that unmanaged applications have been using for over a decade. There’s WPF, which is available to managed code only. There’s Direct2D/DirectWrite, which is available to both managed and unmanaged code, but not compatible (to my knowledge) with WPF.

  2. Nicholas

    Thanks for the comment. Agreed, more design freedom = easier to make a hideous mess. From my quick look, the updated designer in VS 2010 doesn’t really help with this.

    Tim

  3. Also, the look of an application matters far less in business computing than those selling a commercial product: functionality is critical. WPF seems to add an amount of design overhead that most business computing divisions would rather not have to even think about.

  4. Not sure that the arguments for win forms over WPF due to design concerns are particularly valid. The look of the controls is the same as win forms , if you decide not to alter the style. I would agree that there is an argument that several of the out of the box controls that are available in win forms are not available in WPF.
    “design freedom = easier to make a hideous mess”
    Does this mean you are saying developers shouldn’t have the choice to customise the look of controls just in case they make a mess? Or that it should be more difficult to style a control?
    I think the argument needs to not just include “the look” of an application but to the bigger topic of UX. Surely this is one of the problems of LOB applications that no time is given to UX. Can you really separate functionality from UX? This is where WPF’s strengths really start to show, the ability to visualize data and functionality is far easier with much greater flexibility that in win forms.

  5. Out of curiosity, if you typically make a mess in WPF but do fine in Windows Forms, why not just treat WPF like winforms?

    Turn off the xaml view, and start dropping controls on. If the the alignments and margins get in your way, replace the root grid with a Canvas and use good old left/top positioning.

    WPF doesn’t *have* to be harder than windows forms. The real issue isn’t that WPF is harder, it’s that many developers feel that since they have this really capable platform, they have to tap into it…and make a design mess.

    It’s a problem of perception, I think.

    It’s like buying a really fast and sexy car, and then feeling silly if you’re only driving it at 40mph like your other capable, but not so shiny, vehicle. It takes discipline to not put the pedal to the metal and wrap yourself around a tree 🙂

    Pete Brown
    Microsoft

  6. Winforms is great if you are not concerned with having to update control either do to losing the focus on the form which is stacked with different controls or tapping in the control’s pointer to modify the graphics of it. But if you are need a better refresh rate and richer control designs (even if creating one by inheritance) WPF is the way for now to go. You can better much to the same in Winforms as in WPF applications if you are willing to go through the learning curve. After many years dealing with Winforms and the GDI/Win32, I was happy to start using WPF even if I have to use xaml for design (oh well, it was well worth it).

Comments are closed.