Believe it or not, WPF has been around for a while—it shipped as part of Windows Vista in January of 2007, and several of the utilities and system components of Vista make use of it. However, using WPF has not been entirely practical—largely because there were very few tools to make it easier. You can build WPF applications by just writing XAML in notepad, and manually compiling everything, but it isn’t fun or straightforward.
Now, however, Visual Studio 2008 is available, and that makes a huge difference. Finally, building WPF applications is as straightforward as building Windows Forms or MFC apps. There is one caveat, though—the Windows Forms and MFC tools have been around for a while, and have had a chance to mature. The WPF tools are still in their first generation, and there are definitely some holes to be filled. Even so, WPF, with Visual Studio 2008, is now ready for prime time.
This section is going to highlight some of the primary tools in VS 2008 for working with WPF. We will also point out where some of the duct—tape is hiding, and things that we know the VS team is working on improving for the next version.
The XAML Designer
By far the most important WPF tool in Visual Studio 2008 is the XAML designer. This is the combination control that lets you edit XAML directly, or the visual representation of that XAML. Figure 2.12 shows the designer.
Figure 2.12 The Visual Studio XAML editor. We’ve labeled a few of the more interesting elements.
When the designer comes up, it defaults to showing two different panes — the Design Pane and the XAML Pane.
The Design Pane
The design pane shows the visual representation of a XAML file, and will automatically change to reflect any changes to the raw XAML. It is fully interactive, so you can drag elements from the Toolbox. It is also synchronized with XAML Pane, so if you select something in the Design Pane it will automatically be selected in XAML, and vice—versa.
One issue with the design pane is that it can only render legal XAML, so if you break the XAML, you will get a big “Whoops” message up above until you correct your problem. Most of the time, though, the designer does a good job of reflecting what is going on.
The Design Pane also features a Zoom Control in the upper—left corner, which allows you to zoom in and out on your current element. This can be quite handy when you are working on a large window that doesn’t quite fit, or are trying to line up items that you can’t quite see in regular mode. The Zoom takes advantage of the vector—nature of WPF, so there are no pixilation effects—the control simply gets bigger or smaller (figure 2.13). It is also a good way to make sure that you haven’t done something to break DPI independence!
Figure 2.13 When you zoom in and out in the editor, the quality of the various elements is maintained because drawing in XAML is based on vectors, rather than on bitmaps.
The designer has similar auto—position and auto—size features as the Windows Forms editor, where controls can be automatically snapped to reasonable places relative to other controls, although there are differences because of the different positioning/layout behavior of WPF vs. WinForms, which we will discuss in a later chapter. As well as context menus, you also get little handles that let you pull up control—specific behavior—again, pretty similar to WinForms.
The XAML Pane
Because the semantics of XAML are so flexible, there are many things that you simply can’t do directly in the designer. This is especially true in this first release of the WPF tools, but it will probably always be true—there are simply things that you will have to do directly in XAML.
It would be a mistake, though, to simply dismiss the XAML editor as just a place to type raw XML. Probably almost as much work has gone into the XAML editor as the designer, for one major reason—IntelliSense support. We started working with XAML back when there was no Visual Studio release, and we just used a generic XML editor. Believe us when we say the difference is like night and day.
The XAML editor is really good at providing the list of available child—tags, attributes and attribute values, and this is not trivial because, as we said XAML is very flexible. It also manages to catch a large number of errors immediately. This is more than just verifying that you are following the schema—it keeps track of the code as well, and makes sure that there are not illegal mismatches. The XAML editor can also generate code stubs automatically for things like event handlers.
If we had the choice between a 10—times—better visual editor, but with the requirement to use a regular XML editor, or just the XAML editor in Visual Studio, we would take the XAML editor.
Now, with all of that said, the editor still has some rough edges. On the minor end, when new controls are added, you often end up with closed element tags, even when that doesn’t make sense, and, while the editor works well with layouts (see chapter 5), the default behavior is to add a bunch of properties that you invariably have to remove. On the more serious end, one of the things that is missing is something to help with binding (see chapter 11). However, Microsoft assures us that all of these things, and a bunch of others, will be addressed in the next release.
This is not a major feature, but one nice thing about the editor is that you can move the panes so that they are split vertically instead of horizontally, or you can have either the XAML or Design views take up the entire editor, swapping between the two by using the tabs. This is nice if you are about to do a bunch of edits to the XAML, and don’t want to wait for the Design view to catch up. Figure 2.14 shows the different modes.
Figure 2.14 The designer lets you change the orientation of the panes, or lets you collapse the panes so that only one is visible at a time.
You can also swap the panes if you want to so that, for instance, the XAML is at the top and the design view is at the bottom, if you are into that sort of thing. One thing that the editor doesn’t currently have good support for is multiple monitors. We would love to be able to have the XAML on one monitor and the design mode on the other. However, a cute workaround is to split the panes vertically, and then stretch Visual Studio across both screens.