A Tour of WPF in Visual Studio 2008

This article is taken from the book WPF in Action with Visual Studio 2008 published by Manning Publications. It looks at the various features of Visual Studio for working with WPF.

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.

Split Modes

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.

A Tour of WPF in Visual Studio 2008

The Property Grid

Just as with Windows Forms, you can change the various properties of the currently selected control(s) via a Property Grid. However, WPF has made a few changes (figure 2.15).

Figure 2.15 The WPF property grid. It is similar to the Windows Froms property grid, but adds a preview feature and a search option, and has moved the name up to the top.

These may seem like minor things, but the WPF property grid displays a preview of the currently selected control in the top—left hand corner. Also, the name of the current control is now right at the top. The reason we really like this change, though, is that it makes it much easier to make sure you are editing what you think you are editing.

Another very cool thing they have added to the property grid is a Search control that lets you narrow down the properties that are shown. For example, if you type TA, the property list will be limited to those properties that contain the text TA (Tag, TabIndex, HorizonTalAlignment, etc.). If you type TAB, the list will be narrowed down to IsTabStop and TabIndex. Having spent a lot of time searching up and down the property list for a particular property, we think the developer who added this should get a raise and a corner office.

On the downside of the WPF property editor, not all of the properties have the elegent editors that they used to have—often you have to type a string, get an error, then try again. Also, there is currently no event list like Windows Forms has, to show the list of all supported events, and to set up handlers. This will be coming in a future version, but in the meantime, the XAML editor has some support for adding handlers for events, and you can generally double—click on an object in the designer, as you could in WinForms, to get the default event handler (ex: a Click handler for a button).

One thing that is missing—deliberately—from the property grid is the combo—box that Windows Forms had listing all of the controls on the form. While the ability to select a control without having to click on it was handy, the implementation wasn't great—the combobox was not usually wide enough, and it was easy to pick the wrong thing. In WPF, which uses composition to build up complex layouts, it would have been very inadequate. At the same time, being able to find the proper control whose property you want to edit is very important—so important that there are at least 4 different ways to do it!

Selection Controls in Visual Studio

When you want to get to the properties of a particular control, one simple way is to click on the element within the XAML. This will both select the control in the design view and set that control as current in the property editor.

However, if you don't want to search through the XAML, but have a number of overlapping elements, you can right—click on an element in the visual designer, and choose "Select." This gives you access to all of the controls currently under your cursor (Figure 2.16).

Figure 2.16 The Context menu's Select option lets you choose any of the controls under your current location.

Another way of selecting is also pretty cool. At the bottom of the XAML designer is a Path control that shows you the currently selected element, and lets you move to the element's ancestors (figure 2.17).

Figure 2.17 Path control shows you the currently selected element, and all of the element's ancestors.

This control is really easy to miss, but it is a gem. First of all, each ancestor is a hyperlink that will take you to that element. Second of all, you get a little preview of the control so that you can easily see which control you are floating over, and finally, the left/right buttons on the left let you move through a history of your selections.

The final selection tool is equally cool. That is the Document Outline.

The Document Outline

The Document Outline is a tree—view of all of the elements on your window (figure 2.18).

Figure 2.18 The Document Outline. A preview of the currently selected item is automatically generated.

We have to admit—we love the document outline. Particularly when you get into layout, being able to see what is owned by whom is invaluable, and it is a great way of selecting controls that might not be easily accessible. When you click on an item in the Document Outline you get a preview (again, easier to make sure you have the right thing). Also, what you select in the Outline is automatically selected in the designer and in XAML, and the context menu lets you jump to the XAML, or to the properties for the element.

The one downside is that the Document Outline is read—only. We would really love to be able to drag controls from the Toolbox onto the Outline, and to rearrange controls right there using drag—and—drop. The nice thing, though, is that the VS developers agree with us, so we hope to see that functionality in the near future.

These are the major WPF features in Visual Studio 2008, although there are a lot of behind—the—scenes changes to add support. The nice thing is that, when you are writing WPF apps, you are still writing .NET code, so all of the existing framework and tools are there, along with the other new features of .NET 3.x, like LINQ and WCF.

This article is excerpted from WPF in Action with Visual Studio 2008 by Arlen Feldman and Maxx Daymon release July, 2007. Softbound print released November 2008, 520 pages. ISBN: 1-933988-22-3.

This article was originally published on April 6th, 2009
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date