From WinForm to WPF: A Quick Reference Guide

Michael Sorens provides a handy wallchart to help migration between WinForm / WPF, VS 2008 / 2010, and .NET 3.5 / 4.0. this can be downloaded for free from the speech-bubble at the head of the article. He also describes the current weaknesses in WPF, and the most obvious differences between the two.

Michael Sorens provides a handy wallchart to help migration between WinForm / WPF, VS 2008 / 2010, and .NET 3.5 / 4.0. This can be downloaded for free from the bottom of the article. He also describes the current weaknesses in WPF, and the most  obvious differences between the two.

Like many of you, I have been an avid .NET developer / designer for some time, and have been eagerly awaiting both the new design tools of Visual Studio 2010 and the new capabilities of the .NET framework version 4.0 release. At the same time I decided to take the leap from WinForm to Windows Presentation Foundation (WPF) to take advantage of the expressiveness of the technology, and the richness of XAML. WPF is huge, so getting a clear understanding of either of these moves would be daunting; doing both together might seem well nigh overwhelming!

This article is not a starting point for the complete WPF neophyte. If that describes you, you will find this useful only in conjunction with other introductory WPF material. Rather, this article provides explanatory notes to my quick reference chart that could be quite a timesaver as you migrate from Visual Studio 2008 to 2010 and from WinForm to WPF. 

Note: My wallchart, and the discussion of it here, are as accurate as I could make them at the time of writing in March 2010, when Visual Studio 2010 is at “release candidate” stage. You may find inaccuracies, though, due either to my nascent WPF knowledge or simply to the passage of time as technologies change.

How did I get started with WPF? I began by reading the blogs, the reference material, the tutorials, etc. to get a feel for the basics. I then went back through them again as a second pass with the goal of identifying patterns and compartmentalizing. Next I organized the material and put it down on paper as a reference, something that I could then share with the developer community through a vehicle such as this article. (Part of my motivation is self-interest: it also gives me a reference to come back to!) Then I could say that I’d reached my first goal of “getting my feet wet”: still a long way to go!

Not to give away the ending, but you will want to refer to the accompanying cross-reference chart as you read this article—Figure 1 shows a thumbnail. On a single sheet of paper it lets you compare, at a glance, WinForm to WPF, Visual Studio 2008 to 2010, and .NET 3.5 to 4.0 for the toolbox-centric components. That is, it is not a comprehensive comparison for all classes in the .NET framework; rather, it focuses on the components commonly used in the toolbox of Visual Studio’s visual designer.

Figure 1: Thumbnail of the WinForm / WPF Cross-Reference Wallchart

Start at the Beginning

One of the key resources I found to aid my understanding, and to jumpstart the research for this article, comes from MSDN. It a single web page containing Microsoft’s rendering of the differences between WinForm and WPF libraries. it is entitled simply, Windows Forms Controls and Equivalent WPF Controls – see Figure 2. Most of the controls and most of the footnotes from my wallchart come directly from this table. So what value do I add?

Some of the table remarks are too terse for WPF novices; I provide explanations in this article.

  1. Though this web page purports to be the .NET 4.0 version, some entries are not up-to-date. Notice for example, that it shows there is no equivalent for the DataGridView when, in fact, there is: the newly incorporated WPF DataGrid control.
  2. When there is no WPF equivalent, the MSDN page halts right there. I provide for almost every such instance suggestions or alternatives for the WinForm control.
  3. My wallchart groups controls into categories, particularly useful because a pair of equivalent WinForm / WPF controls might not both start with the same letter.
  4. The MSDN web page is missing a few components from the Visual Studio toolboxes; I have included all toolbox controls in the wallchart.

Perhaps most importantly, my wallchart highlights the key changes between WinForm and WPF, Visual Studio 2008 and 2010, .NET 3.5 and 4.0, and it highlights components not in the primary namespaces for WinForm and WPF controls.

Figure 2: Thumbnail of the MSDN Reference Page

Figure  3 WinForm and WPF Toolboxes in Visual Studio 2010

Toolbox Categories

The components of the wallchart are grouped into categories corresponding closely to those in the WinForm toolbox from either VS20008 or 2010 (see Figure 3). So, for example, if you are looking for a printing control look in the Printing category. The WinForm toolbox also conveniently provides the All Windows Forms category (at the very top) that duplicates all the controls in all the other categories into a single, alphabetical list. You thus have immediately at hand two ways to hunt for a control that you may not be familiar with.

Strangely, this simple, dual-lookup capability escaped inclusion in the WPF toolbox, which just dumps all the controls into two lists: one for common controls and one for all controls. While I think the Visual Studio team did an outstanding job overall, this is one large gap in usability! I discussed this with one person on the VS team who told me that it was a conscious team decision because they thought it was easier for developers to find an unknown control by looking it up alphabetically. I disagree, but no need to cater to one preference or the other, simply give the user the choice, just as the WinForm toolbox does. You can track this issue on the defect report I entered on Microsoft Connect (WPF Toolbox should mirror WinForm toolbox).  As a side note, I will concede that the VS 2010 WPF toolbox is a lot better than the VS2008 WPF toolbox, which had a strange defect: the list of controls repeats 4 times in the toolbox!

WPF Improvements with 4.0

Observe from the wallchart that .NET 4.0 provided significant improvement over .NET 3.5 by the inclusion of the DatePicker, Calendar, and DataGrid controls (see Figure 4). Those were marked red (indicating significant omission) in the .NET 3.5 column but changed to green (indicating something really good happened!) in the .NET 4.0 column. These were available to savvy 3.5 users via the WPF Toolkit provided by Microsoft. The WPF Toolkit “… is a collection of WPF features and components that are being made available outside of the normal .NET Framework ship cycle. The WPF Toolkit not only allows users to get new functionality more quickly, but allows an efficient means for giving feedback to the product team. Many of the features will be released with full source code as well. Over time, some of these features may be moved into the .NET Framework, based on readiness and customer feedback.” True to the spirit suggested, the important controls mentioned above were moved into the .NET 4.0 release. So take heart that the significant Chart control, glaringly omitted from .NET 4.0 and sorely missed, is already unofficially available in the WPF Toolkit.

Figure 4: Significant New WPF Controls in .NET Framework 4.0

The Visual / Non-Visual Distinction in Winform and WPF

Most WinForm controls in the toolbox are for visual components: a button, a dialog, a container, etc. There are, however, some that are non-visual, like the BackgroundWorker or the BindingSource. When you drag one of these non-visual components onto the designer surface, it does not appear directly on the surface but instead it is placed in the component tray just below. So though you cannot manipulate it on the designer surface, you still have access to all its properties in the property pane, with all the convenience that that provides. This is notable here because some of these non-visual components come from a part of the .NET framework that is not directly associated with WinForm or WPF classes, determined by examining the namespace where a class resides. WinForm components live in the System.Windows.Forms namespace. WPF components, on the other hand, live in the System.Windows.Controls.Primitives, System.Windows.Controls, or System.Windows.Shapes namespaces (plus the top-level Window component that resides in just System.Windows).

The BackgroundWorker, for example is in the System.ComponentModel namespace. As such, it is not really valid to say, as the wallchart intimates, that because this component exists in the WinForm environment but not in the WPF environment it is therefore a drawback for WPF. Thus, you will not find the WPF slot highlighted in red for this component.

But why the difference? That is, why does the WinForm toolbox show non-visual components but the WPF toolbox only shows visual components? For the answer I went to the source in the person of Rob Relyea, a member of the WPF development team at Microsoft. According to Rob, “[they] haven’t invested in this yet because the runtime does not support non-visual components. We believe the right place to persist non-visual components is in the Resources block of the form but in WPF you cannot name resources and they need a name to be programmatically accessible.”

WPF Weaknesses

So ignoring non-visual component differences, true weaknesses comparing WinForm to WPF are highlighted in red on the wallchart. I have differentiated these elements with some that are present but incomplete with respect to WinForm (e.g. ComboBox does not do autocomplete) using orange highlighting. Microsoft may include these in later releases but until then I provide below some workarounds and solutions if you need these now.

Component
Alternatives
PropertyGrid
This CodePlex project provides one implementation: Codeplex: WPF Property Grid
Chart
A pre-release version is available now as part of the WPF Toolkit (Codeplex: Windows Presentation Foundation (WPF) Toolkit).
ColorDialog
An unofficial Color Picker dialog is discussed on this Microsoft blog (Uncommon Dialogs: Font Chooser & Color Picker Dialogs ). The blog post also includes the link to download the control.
FontDialog
An unofficial Font Chooser dialog is available from this Microsoft blog (Uncommon Dialogs: Font Chooser & Color Picker Dialogs ). 
PrintPreviewDialog
One solution is discussed in this StackOverflow thread: stackoverflow: how do I do print preview when using a documentpaginator to print?
PageSetupDialog
Though one esteemed authority on WPF, Charles Petzold, says it exists in WPF (Printing under WPF ) it “just ain’t so.” And the only solutions I have found to filling in this gap all say to just use the WinForm component.
FolderBrowserDialog
I found one solution that wraps the WinForm component into WPF: How to use a FolderBrowserDialog from a WPF application. For details on using WinForm components in WPF see Hosting a Windows Forms Control in WPF at Walkthrough: Hosting a Windows Forms Control in WPF.
ComboBox
The WPF ComboBox, unlike the WinForm variant, does not support auto-completion. However, the new AutoCompleteBox is now available in the WPF Toolkit (WPF Toolkit).
OpenFileDialog SaveFileDialog
These do not exist in WPF but you can use the versions in the Microsoft.Win32 namespace—see Common Dialogs at (Dialog boxes Overview:Common Dialog Boxes ). If you have a need to customize these dialogs, I found an interesting article on extending them at (Extend OpenFileDialog and SaveFileDialog Using WPF ).
NumericUpDown DomainUpDown
Microsoft provides several variations of implementing a NumericUpDown—see Control Customization Samples at (Windows Presentation Foundation Samples
Control Customization Samples
). Microsoft’s equivalence reference mentioned earlier indicates that both NumericUpDown and DomainUpDown may be composed with “a TextBox and two RepeatButtons”. Like all erudite works, however, the details are left as an exercise. Being a neophyte with WPF myself, those details are not yet obvious to me so I cannot comment on this purported remedy.
UniformGrid
This WPF component is present in both .NET 3.5 and .NET 4.0 but it was removed from the toolbox in Visual Studio 2010. Presumably this decision came about after experience with WPF in VS 2008. It is unfair to list this as a weakness (since you could simply create one in XAML if you need it) but I did not have a better place to list this unique situation.

WPF / WinForm Differences

WPF provides a far richer toolset for developing front ends compared to WinForms but, as shown in the previous section, it does have a few deficiencies. On the other hand, there are some things that WPF simply does differently. These still appear as gaps on the wallchart, but they have yellow footnotes with terse explanations rather than red flags. This section provides a bit more detail about each of those footnoted items.


ErrorProvider
This is not present in WPF but WPF provides a much broader validation capability. See this post at the Joy of Code, for example (The Joy of Code: Reason 10. Validation) or this at Code Project (Validation in Windows Presentation Foundation ).
HelpProvider
According to MSDN, this is not present in WPF because you are supposed to use a Tooltip instead. Tooltips are much more powerful and flexible in WPF, allowing them to contain compound controls, formatted text, etc. so this may certainly be adequate for most needs. However, I did find this blog entry from Mike Hillberg on how to create an F1 help provider (A Context-Sensitive Help Provider in Wpf ).
ImageList
I could not find specific references as to the way to achieve the same result in WPF provided by the WinForm ImageList control but it sounds to me like the richness of WPF lets the standard ListBox control handle anything you would need an ImageList for. Josh Smith provides a tutorial and code for manipulating images in a ListBox here: Custom ListBox Layout in WPF.
LinkLabel
This control is absent from WPF but you can use the Hyperlink (.NET Framework Class Library: Hyperlink Class) control (in the System.Windows.Documents namespace, which is also part of the WPF framework) to achieve the same effect. Note that in order to make a working hyperlink the Hyperlink element must have some parent that is a navigation host, including NavigationWindow or Frame. (A common frustration is hosting inside a plain Window and wondering why it does not work.)

Where To Go From Here

WPF is vast. My suggestion is to find some good books or articles that seem to know what they are talking about, then read and reread and reread again! In your journey, you will probably find it helpful to have some quick references by your side such as the one I have presented here. Here are a few more that may assist you: