XAML is defined as a language consisting of a collection of elements, attributes, and related objects. These objects are referenced from the XAML namespace, which by convention precedes each class with an x :. .NET extends and maps these declarative structures into .NET.

Before getting to the syntax, take a look at the three categories of XML statement you will find within the XAML namespace: attribute, markup extension, and XAML directive. Each is a separate category of language element.

Within XML, attributes refer to named properties that are associated with a given XML node. Thus, the XML node object might have several attributes such as ID, Name, Text, and so on associated with it. These attributes in XML live within the definition of the XML node. They are not contained within the XML node but its definition, as shown here:

<object id="myObject"></object>

Within XAML, the list of attributes includes those in the following table. Be aware that the term "object" in the following snippets can be replaced with one of several WPF objects, including Application, Window, Button, Brush, and so on:

Notice that none of the preceding attributes are actually referenced as a node within XML. Instead, they modify the properties associated with a node. Thus, the attributes are modifiers, as opposed to the next category of elements: markup extensions. As implied by the word "extensible" in the name Extensible XML, one of the features of this model is that the format allows for the definition of extensions. These extensions expand on the base elements associated with that markup definition. XAML includes a limited number of such extensions. Unlike an attribute, a markup extension can be used to create an XML node or a collection of XML attributes. When used to create a node, the markup extension allows for the definition of property values within this node. When used to allow for the creation of a collection of attributes, it can be recognized by the surrounding curly braces, as shown in the preceding TypeArguments definition. Markup extensions for XAML are shown in the following table:

Don't let that last extension confuse you; there are two ways that markup extensions are used — either as attributes contained within curly braces or as nodes that may contain their own attributes and properties. Some, such as x:Static, always appear as attributes; others, such as x:Null and x:Array, always appear as nodes; and of course x:Type can be found in either location. Up until now, all the XAML language elements have been used to operate within the definition of XML. That is, they define attributes and nodes, and as long as you understand the definition of the keyword, you can understand the data it references.

However, at times you need to truly reference data. For example, none of the preceding extensions would support embedding other XML data into your XAML file or referencing code directly from within your XAML file. These two capabilities are available based on XAML directives. XAML directives enable you to embed elements that don't follow the XML formatting rules. There are two such directives:

As you can see, the scope of the XML definition for what you're going to see within a XAML file is not that complex. You're probably wondering where all the controls, windows, and even the application object that we've already seen in action are. These items, while defined as part of the WPF implementation, are not part of the core XAML language definition. They are the WPF extensions, and the reason why you added a second namespace reference to the Presentation folder. Everything else you see in XAML that falls into this second category is also available for reference from your .NET application, so let's take a look at the integration of XAML and Visual Basic.

It is possible to do much of your WPF programming using XAML, but the next step is to examine how XAML can be integrated with code. After all, at some point you probably expect to start seeing some Visual Basic code again. Until now the ProVB_WPF sample has been a pure XAML application, so first we will make a quick plan for what this application will do and then we will create a first-cut implementation. For demonstration purposes, we will create a simple photo-viewing application. The user should be able to select a folder containing one or more images and then view those images, moving forward and backward through the list.

For now, that will be the limit of the requirements; later, after the basic application is operational, you can expand the scope to customize the look and feel further. Begin by modifying the "empty" window. Of course, it's not really empty. The window actually has a grid within it, so you can start with that and create three sections. After selecting the grid, hover over the left-hand border of your window. You'll see a point appear within the border that sends a guide line horizontally across the window. Select a point about 40 pixels from the top and a second point around 40 pixels from the bottom, dividing your grid into three sections.

Don't worry about being exactly on 40, because after you've selected your two points you are going to switch to the XAML view. Now, instead of the previous default display, you have code similar to what appears in the following block:

<Window x:Class="Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Title="ProVB_WPF" Height="335" Width="415" Name="MainWindow">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="45" />
            <RowDefinition Height="215*" />
            <RowDefinition Height="40" />
        </Grid.RowDefinitions>
    </Grid>
</Window>

This may look familiar because the preceding code includes a few edits that you can reproduce at this point. Note that the title of the window has been modified to match the project name. On this same line, you can see that the default size of the window has changed, and that the name of this instance of the Window1 class is now MainWindow. These are relatively minor in comparison to the newly added lines in this file.

The XAML now includes a new section related to the Grid.RowDefinitions. This section contains the specification of sections within the points in the grid. When you selxected those points in the designer, you were defining these sections. The default syntax associated with the height of each section is the number of pixels followed by an asterisk. The asterisk indicates that when the window is resized, this row should also resize. For this application, only the center section should resize, so the asterisk has been removed from the top and bottom row definitions.

This provides a set of defined regions that can be used to align controls within this form. Thus, the next step is to add some controls to the form and create a basic user interface. In this scenario, the actions should be very familiar to any developer who has worked with either Windows Forms or ASP.NET forms.

WPF provides an entirely different set of libraries for developing applications. However, although these controls exist in a different library, how you interact with them from Visual Basic is generally the same. Each control has a set of properties, events, and methods that you can leverage. The XAML file may assign these values in the declarative format of XML, but you can still reference the same properties on the instances of the objects that the framework creates within your Visual Basic code.

Starting with the top section, drag the following from the Toolbox onto the form: a label, a text box, and a button control. These can be aligned into this region in the same order they were added. Ensure that the label is bound to the left side and top of the window, while the button is bound to the right side and top of the window. Meanwhile, the text box should be bound to the top and both sides of the window so that as the window is stretched, the width of the text box increases. The resulting XAML should be similar to this:

<Window x:Class="Window1"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="ProVB_WPF" Height="335" Width="415" Name="MainWindow">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="45" />

<RowDefinition Height="215*" />
            <RowDefinition Height="40" />
        </Grid.RowDefinitions>
        <Label Margin="0,11,0,0" Name="Label1" HorizontalAlignment="Left" Width="80"
Height="23" VerticalAlignment="Top">Image Path:</Label>

        <TextBox Margin="81,13,92,0" Name="TextBox1" Height="21"
VerticalAlignment="Top" />

        <Button HorizontalAlignment="Right" Margin="0,11,9,11" Name="ButtonBrowse"
Width="75">Images ...</Button>
    </Grid>
</Window>

As shown in the newly added lines, each control is assigned a name and defines a set of editable properties. Note that these names can be addressed from within the code and that you can handle events from each control based on that control's named instance. For now, however, just adjust the text within the label to indicate that the text box to its immediate right will contain a folder path for images, and adjust the button control. Place a new label on the button control's Images and rename the control to ButtonBrowse. There is obviously more to do with this button, but for now you can finish creating the initial user interface.

Next, add the following controls in the following order. First, add an Image control. To achieve a design surface similar to the one shown in Figure 17-3, drop the Image control so that it overlaps both the middle and bottom sections of the grid display. Now add three buttons to the bottom portion of the display. At this point the controls can be aligned. You can do this through a combination of editing the XAML directly and positioning things on the screen. For example, expand the image control to the limits of the two bottom grid rows using the design surface; similarly, align the buttons visually on the design surface.

Figure 17.3. Figure 17-3

As shown in the figure, the separations for the two row definitions are described in the design surface, and each of the buttons has a custom label. Note that the Next button is followed by a pair of greater than symbols, but the Prev button is missing a matching set of less than symbols. The problem is that the less than and greater than symbols have special meaning in XAML, so it can be difficult to use them in the XAML. Therefore, one of the changes to be made in the Visual Basic code is the addition of these symbols to the button label.

First, however, review the XAML code and ensure that, for example, the Image control is assigned to Grid.Row 1 and that the property Grid.RowSpan is 2. Unlike the items that were in Grid.Row 0, the items in other rows of the grid must be explicitly assigned. Similarly, the name and caption of each button in the bottom row of the grid are modified to reflect that control's behavior. These and similar changes are shown in the following XAML:

<Window x:Class="Window1"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="ProVB_WPF" Height="335" Width="415" Name="MainWindow">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="45" />
            <RowDefinition Height="215*" />
            <RowDefinition Height="40" />
        </Grid.RowDefinitions>
        <Label Margin="0,11,0,0" Name="Label1" HorizontalAlignment="Left" Width="80"
Height="23" VerticalAlignment="Top">Image Path:</Label>

        <TextBox Margin="81,13,92,0" Name="TextBox1" Height="21"
VerticalAlignment="Top" />

        <Button HorizontalAlignment="Right" Margin="0,11,9,11" Name="ButtonBrowse"
Width="75">Images ...</Button>

        <Image Grid.Row="1" Grid.RowSpan="2" Margin="0,0,0,0" Name="Image1"
Stretch="Fill" />

        <Button Grid.Row="2" HorizontalAlignment="Right" Margin="0,0,15,8"
Name="ButtonNext" Width="75" Height="23" VerticalAlignment="Bottom">Next >>
</Button>

        <Button Grid.Row="2" HorizontalAlignment="Left" Margin="15,0,0,8"
Name="ButtonPrev" Width="75" Height="23" VerticalAlignment="Bottom">
Prev</Button>

        <Button Grid.Row="2" Margin="150,0,150,8" Name="ButtonLoad" Height="23"
VerticalAlignment="Bottom">View Images</Button>
    </Grid>
</Window>

Note in the shaded sections the description of the new controls. The Image control is first, and it is positioned in Grid.Row number 1, which, because .NET arrays are always zero-based, is the second row. The second attribute on this node indicates that it will span more then a single row in the grid. For now, this control uses the default name, and it has been set so that it will stretch to fill the area that contains it.

Following the Image control are the definitions for the three buttons along the bottom of the display. For now, these buttons will control the loading of images; over the course of this chapter, these buttons will be either removed or redone significantly. The order of these buttons isn't important, so following their order in the file, the first button is like the others positioned in the final row of the grid. This button has been placed on the right-hand side of this area and is bound to the bottom and right corners of the display. Its name has been changed to ButtonNext and its label is Next >>.

The next button is the Prev button, which has been placed and bound to the left-hand side and bottom of the display. Its name has been changed to ButtonPrev, and its display text has been changed to read Prev. As noted, the arrow symbols are not in the button name; and, as you can test in your own code, attempting to add them here causes an error.

Finally, there is the ButtonLoad button, which is centered in the display area. It has been bound to both sides of the display to maintain its position in the center. The label for this button is View Images, which is, of course, the goal of this application. However, in order for that to happen, you need an event handler for this button; in fact, you need several event handlers in order to get the basic behavior of the application in place.

Begin by adding some event handlers to the application. In previous versions of Visual Studio you could click on a control and Visual Studio would automatically generate the default event handler for that control in your code. Fortunately, WPF also provides this behavior, so generate the following event handlers:

To create each of these handlers, you need to return to the design display and click on the associated control, but after they are created you can stay in code mode for most of this section. Take a look at the ButtonBrowse_Click event handler's method stub:

Private Sub ButtonBrowse_Click(ByVal sender As System.Object, _
     ByVal e As System.Windows.RoutedEventArgs) _
     Handles ButtonBrowse.Click
End Sub

The preceding code was reformatted with line extension characters to improve readability, but this is essentially what each of your event handlers looks like. As a Visual Basic developer, you should find this syntax very familiar. Note that the method name has been generated based on the control name and the event being handled. The parameter list is generated with the "sender" and e parameter values, although the e value now references a different object in the System.Windows namespace. Finally, defined here is the VB-specific Handles syntax that indicates this method is an event handler and which specific event or events it handles.

While this is a very familiar, powerful, and even recommended way of defining event handlers with VB and WPF, it isn't the only way. WPF allows you to define event handlers within your XAML code. To be honest, if this were a book on C#, we would probably spend a fair amount of time covering the advantages of that type of event handler declaration. After all, C# doesn't support the direct association of the event handler declaration with the method handling the event; as a result, C# developers prefer to declare their event handlers in XAML.

However, one of the goals of XAML is the separation of the application logic from the UI, and placing the names of event handlers in the UI actually couples the UI to the business logic. It shouldn't matter to the UI whether the Click event or the DoubleClick or any other event is being handled by custom logic. Therefore, although this section introduces the way to define events directly in XAML, the recommendation is to define event handlers with the code that implements the handler.

In order to demonstrate this in the code, return to the design view for your form. Select the Images button and position your cursor just after the word Button, which names this node. Press the spacebar. You'll see that you have IntelliSense, indicating which properties and events are available on this control. Typing a c adjusts the IntelliSense display so that you see the Click event. Select this event by pressing Tab and you'll see the display shown in Figure 17-4.

Figure 17.4. Figure 17-4

As shown here, not only does the XAML editor support full IntelliSense for selecting properties and events on a control, when an event is selected, it displays a list of possible methods that can handle this event. Of particular note is the first item in the list, which enables you to request that a new event handler be created in your code. Selecting this item tells Visual Studio to generate the same event handler stub that you created by double-clicking on the control; however, instead of placing the Handles clause on this method, the definition of this method as an event handler is kept in the XAML.

This causes two issues. First, if you are looking only at the code, then nothing explicitly indicates whether a given method in your code is in fact an event handler. This makes maintaining the code a bit (not a lot) more difficult to maintain. Second, if you have handled an event that is specific to Windows as opposed to the Web, then your XAML won't be portable. Neither of these side effects is desirable. Thus, given the VB syntax for defining events as part of the method declaration, the code in this chapter avoids the embedded XAML style of declaring standard Windows event handlers. At this point, you could run your application. It won't do anything except allow you to close it, but you can verify that it behaves as expected and save your work.

It's almost time to make this UI do something, but there is one more step before you start working with code. As part of this application, you want to allow users to select the directory from which images should be displayed. In theory, you could (and in practice, at some time probably would) write a custom interface for selecting or navigating to the images directory. However, for this application that isn't important, and you want a quick and easy solution.

Unfortunately, WPF doesn't offer any native control that supports providing a quick and easy view into the file system. However, Windows Forms does, and in this case you want to leverage this control. The good news is that you can, and the even better news is that you don't need the Windows interop library in order to do so. Because something like the Browse Folders dialog isn't a control hosted on your form, you can reference it from your code. Thus, although you need the Windows Forms Integration Library and the WindowsFormsHost control discussed in Chapter 18 for any UI-based controls, in this case the code just needs to reference the System.Windows.Forms library.

Because the System.Windows.Forms library isn't automatically included as a reference in a WPF application, you need to manually add a reference to this library. Open the My Project display and select the References tab. Click the Add button to open the Add Reference dialog and then select the System.Windows.Forms library, as shown in Figure 17-5. You can't add controls to your WPF form without leveraging the Windows.Forms.Integration library, but you can, behind the scenes, continue to reference controls and features of Windows Forms.

With this additional reference, you can begin to place some code into this application. Start with the window_loaded event. This event is where you'll define the default path for the image library, set up the label for the Prev button, and change the default property of the grid control so that it handles the images the way you want:

Private Sub Window1_Loaded(ByVal sender As System.Object, _
                           ByVal e As System.Windows.RoutedEventArgs) _
                           Handles MyBase.Loaded
    ' Append the << to the text for the button since these are _
    ' reserved characters within XAML
    ButtonPrev.Content = "<< " + ButtonPrev.Content.ToString()
    ' Set the default path from which to load images
    TextBox1.Text = _
           Environment.GetFolderPath(Environment.SpecialFolder.MyPictures)

' Have the images maintain their aspect ration
    Image1.Stretch = Stretch.Uniform
End Sub

Figure 17.5. Figure 17-5

The preceding implementation handles these three tasks. It takes the content of the ButtonPrev control and appends the two less than symbols to the front of the string so that both buttons are displayed uniformly. Of course, long term, this code is going to be disposed of, but for now it helps illustrate that while controls such as Button may seem familiar from Windows Forms, these controls are in fact different. The WPF version of the Button control doesn't have a text property; it has a content property. The content property is, in fact, an untyped object reference. In the case of this application, you know this content is a string to which you can append additional text. However, this code is neither a good idea nor easily maintained, so this is just a temporary solution.

Next, the code updates the text property of the TextBox control used on the form. This text box displays the folder for the images to display. In order to provide a dynamic path, the code leverages the Environment class to get a folder path. To this shared method the code passes a shared environment variable: Environment.SpecialFolder.MyPictures. This variable provides the path to the current user's My Pictures folder (on Vista, the Pictures folder). By using this value, the code automatically points to a directory where the current user would be expected to have images.

Finally, to again demonstrate that any of the WPF classes can in fact be modified within your code, this code sets a property on the image control. Specifically, it updates the Stretch property of the Image control to ensure that images are resized with their aspect maintained. Thus, if an image is square, then when your image control becomes a rectangle, the image remains square. The Stretch.Uniform value indicates that aspect should be maintained, while other members of the Windows.Stretch enumeration provide alternative behavior.

The next step is to implement your first button handler, the ButtonBrowse_Click handler. When this button is clicked, the application should open the Folder Browse dialog, displaying the currently selected folder as the default. The user should be allowed to navigate to an existing folder or create a new folder. When the dialog is closed, the application should, if the user selected a new folder, update the folder's text box to display this new location:

Private Sub ButtonBrowse_Click(ByVal sender As System.Object, _
                               ByVal e As System.Windows.RoutedEventArgs) _
                               Handles ButtonBrowse.Click
    Dim folderDialog As System.Windows.Forms.FolderBrowserDialog = _
                          New System.Windows.Forms.FolderBrowserDialog()
    folderDialog.Description = "Select the folder for images."
    folderDialog.SelectedPath = TextBox1.Text
    Dim res As System.Windows.Forms.DialogResult = _
                                                folderDialog.ShowDialog()
    If res = System.Windows.Forms.DialogResult.OK Then
        TextBox1.Text = folderDialog.SelectedPath
    End If
End Sub

The preceding code block declares an instance of the System.Windows.Forms.FolderBrowserDialog control. As noted when the reference was added, this control isn't part of your primary window display, so you can create an instance of this dialog without needing the Windows.Forms.Interface library. It then sets a description indicating to users what they should do while in the dialog, and updates the current path for the dialog to reflect the currently selected folder. The dialog is then opened and the result assigned directly into the variable res. This variable is of type System.Windows.Forms.DialogResult and is checked to determine whether the user selected the OK or Cancel button. If OK was selected, then the currently selected folder is updated.

Now it's time to start working with the images. That means you need to retrieve a list of images and manipulate that list as the user moves forward and backward through it. You could constantly return to the source directory to find the next and previous images, but you will get much better performance by capturing the list locally and keeping your current location in the list. This implies two local variables; and because you want these variables available across different events, you need to declare them as member variables to your class:

Class Window1
    Private m_imageList As String() = {}
    Private m_curIndex As Integer = 0
    Private Sub Window1_Loaded(ByVal sender As System.Object, _
                               ByVal e As System.Windows.RoutedEventArgs) _
                               Handles MyBase.Loaded
        ' Append the << to the text for the button since these are _
        ' reserved characters within XAML
        ButtonPrev.Content = "<< " + ButtonPrev.Content.ToString()
        ' Set the default path from which to load images
        TextBox1.Text = _
               Environment.GetFolderPath(Environment.SpecialFolder.MyPictures)
        ' Have the images maintain their aspect ration
        Image1.Stretch = Stretch.Uniform
    End Sub

Private Sub ButtonBrowse_Click(ByVal sender As System.Object, _
                               ByVal e As System.Windows.RoutedEventArgs) _
                               Handles ButtonBrowse.Click
    Dim folderDialog As System.Windows.Forms.FolderBrowserDialog = _
                          New System.Windows.Forms.FolderBrowserDialog()
    folderDialog.Description = "Select the folder for images."
    folderDialog.SelectedPath = TextBox1.Text
    Dim res As System.Windows.Forms.DialogResult = _
                                                folderDialog.ShowDialog()
    If res = System.Windows.Forms.DialogResult.OK Then
        TextBox1.Text = folderDialog.SelectedPath
    End If
End Sub
Private Sub ButtonLoad_Click(ByVal sender As System.Object, _
                             ByVal e As System.Windows.RoutedEventArgs) _
                             Handles ButtonLoad.Click
    Image1.Source = Nothing
    m_imageList = System.IO.Directory.GetFiles(TextBox1.Text, "*.jpg")
    m_curIndex = 0
    If m_imageList.Count > 0 Then
        Image1.Source = _
                       New System.Windows.Media.Imaging.BitmapImage( _
                               New System.Uri(m_imageList(m_curIndex)))
    End If
End Sub

The beginning of the preceding code adds two new properties to class Window1. Both values are private variables that have not been exposed as public properties. They are being made available for use in the image-handling buttons. Your code should look similar to the preceding code. The second shaded section is an implementation of the ButtonLoad event handler. This event handler is called when the user clicks ButtonLoad, and the first thing it does is clear the current image from the display. It then leverages the System.IO.Directory class, calling the shared method GetFiles to retrieve a list of files. For simplicity, this call screens out all files that don't have the extension .jpg. In a full production application, this call would probably use a much more complex screening system to gather all types of images and potentially feed a folder navigation control so that users could change the selected folder or even add multiple folders at once.

Once the list of files is retrieved and assigned to the private variable m_imageList, the code clears the current index and determines whether any files were returned for the current directory. The screenshots in this chapter have three images in the folder in order to obtain a small array; however, if no images are present, then the code exists without displaying anything. Here, presume an image is available. The code uses the System.Windows.Media.Imaging class to load an image file as a bitmap. It does this by accepting the URI or path to that image, a path that was returned as an array from your call to GetFiles. Note that the BitmapImage call doesn't need an image formatted as a bitmap, but instead converts the chosen image to a bitmap format that can then be directly referenced by the source property of the Image control:

Private Sub ButtonPrev_Click(ByVal sender As System.Object, _
                             ByVal e As System.Windows.RoutedEventArgs) _
                             Handles ButtonPrev.Click
    If m_imageList.Count > 0 Then

m_curIndex -= 1
            If m_curIndex < 0 Then
                m_curIndex = m_imageList.Count - 1
            End If
            Image1.Source = New System.Windows.Media.Imaging.BitmapImage( _
                                      New System.Uri(m_imageList(m_curIndex)))
        End If
    End Sub

    Private Sub ButtonNext_Click(ByVal sender As System.Object, _
                                 ByVal e As System.Windows.RoutedEventArgs) _
                                 Handles ButtonNext.Click
        If m_imageList.Count > 0 Then
            m_m_curIndex += 1
            If m_curIndex > m_imageList.Count - 1 Then
                m_curIndex = 0
            End If
            Image1.Source = New System.Windows.Media.Imaging.BitmapImage( _
                                      New System.Uri(m_imageList(m_curIndex)))
        End If
    End Sub
End Class

After the code to load an image has been added, implementing the ButtonPrev and ButtonNext event handlers is fairly simple. In both cases the code first checks to ensure that one or more images are available in the m_imageList. If so, then the code either decrements or increments the m_curIndex value, indicating the image that should currently be displayed. In each case the code ensures that the new index value is within the limits of the array. For example, if it is below 0, then it is reset to the last image index; and if it is greater than the last used index, the counter is reset to 0 to return it to the start of the list.

The next logical step is to run the application. Clicking the Run button within Visual Studio ensures that your application starts. If you have images loaded in your Pictures folder, then you can open the first of these images in the application. If not, then you can navigate to another directory such as the Samples folder using the Images button. At this point, you'll probably agree that the sample application shown in Figure 17-6 looks just like a typical Windows Forms application — so much so in fact that the next steps are included to ensure that this doesn't look like a Windows Forms application.

However, before adding new features, there is a possibility that when you loaded your image, your application didn't display the image quite like the one shown in Figure 17-6; in fact, it might look more like the image shown in Figure 17-7. If, when you worked on your own code, you added the Image control after adding the View, Prev, and Next buttons, then your buttons — in particular, the View Images button — might be completely hidden from view. This is caused by the way in which WPF layers and loads controls, and to resolve it you need to change the order in which the controls are loaded in your XAML. Before doing that, however, this is a good place to discuss layers and the WPF layering and layout model.

WPF supports a very robust model for control layout, which it achieves by leveraging the capability to layer controls and by providing a set of controls directly related to layout. Combined with the capability to define a reasonable set of layout information for each control, what you wind up with is an adaptable environment that can, at the extreme, provide unique behavior.

Figure 17.6. Figure 17-6

How does the process work? Within each control are the basic elements associated with the sizing of that control. As with past versions of Windows Forms, included is the concept of height and width and the four associated limitations: MaxHeight, MaxWidth, MinHeight, and MinWidth. Additionally, as shown in this chapter, it is possible to bind controls to window borders.

The layout properties aren't the focus of this section, however. More important is the concept of layered controls. What happens when you layer an image on top of something such as a grid? Recall how the Image control you defined was bound to the four borders of its display area. In fact, the control isn't bound to the limits of the window per se; it is bound to the limits of the grid control upon which it is explicitly layered. This layering occurs because the Image control is defined as part of the content of the grid. That content is actually a collection containing each of the layered controls for the selected control.

When it comes to layout and layering, keep in mind that if a control is explicitly layered on top of another control as part of its content, then its display boundaries are by default limited by the containing control's boundaries.

You can override this behavior using the ClipToBounds property, the LayoutClip property, and the GetLayoutClip method of the container. Note, however, that the default behavior of WPF controls is to set ClipToBounds to false and then use the LayoutClip property and the GetLayoutClip method to specify the actual clipping bounds. Resetting and manually managing the clipping behavior enables a control to be drawn outside the bounds of its parent container. That behavior is beyond the scope of this chapter, as the process is somewhat involved and the preferred behavior, when available, is to clip within the region of the parent control.

The fact that your control can be drawn beyond the limits of its container is an important concept. It means your controls are no longer "contained," but rather are truly layered. This may sound trivial, but the implications are significant. Under previous UI models, an object had a container of some sort. For example, a panel could contain other controls of certain types, but not necessarily all types. A button's content was generally text unless you had a button configured for images, but you couldn't really find a button configured to contain, for example, a drop-down list box, unless you wrote a custom display implementation.

By moving to a more layered approach, you can create a single control that handles text, images, and other controls. The technique chosen to accomplish that was for those controls that support layering to include a content presenter control. Thus, when you indicated that the Image control in ProVB_WPF should stretch, it stretched in accordance with the grid control. Were you to change the XAML definition of the grid control and give it a fixed height or width, then even though the window might change, the Image control would still be bound to the limits of the grid control.

This behavior is explicit layering, and it is only available with certain control types. For example, WPF provides a series of different "panel" controls that are used to provide a framework for control layout. The grid is probably the one most familiar to .NET Windows Forms developers because it maps most closely to the default behavior of Windows Forms. Other similar controls include StackPanel, Canvas, DockPanel, ToolBar, and Tab-related controls. Each of these provides unique layout behavior. Because these are available as controls, which you can nest, you can combine these different layout paradigms within different sections of a single form, which enables you to group controls and achieve a common layout behavior of related controls.

To be clear, however, explicit layering or nesting isn't just available with panel controls; another WPF example is the Button control. The button has a layer of generic button code — background color, border, size, and so on — that is managed within the display for the button. Then the button has a content presenter within its definition that takes whatever was placed into the button's content property and calls the presentation logic for that control. This enables the button and many other controls to contain other controls of any type.

You can place a button on a form and bind it to the form's borders, and then place other controls on the form. Because the button exposes a content property, it supports explicit layering, and other controls can in fact be placed within the content of the button. Thus, whenever a user clicks on the surface of the form, a click event is raised to the underlying button that is the owner of that content. The fact that WPF controls forward events up the chain of containers is an important factor to consider when capturing events and planning for application behavior. The formal name for this behavior is routed events.

Routed events are a key new concept introduced with WPF, and they are important in the sense that as you add controls to your UI, you create a hierarchy. In the example thus far, this hierarchy is rather flat: There is a window, and then a grid, and each of the controls is a child of the grid. However, you can make this hierarchy much deeper, and routed events enable the controls at the top of the hierarchy to be notified when something changes in the controls that are part of their content structure.

In addition to these explicit concepts of layering, hierarchy, and routed events, WPF also has the concept of implicit layering. An implicit layer describes the scenario when you have two different controls defined to occupy the same space on your form. In the case of the example code, recall that the image was defined to overlay both of the row definitions, including the one containing the three Image control buttons. Thus, these controls were defined to display in the same area, which isn't a problem for WPF, but which in the current design isn't ideal for display purposes either.

The key idea is that there is implicit layering and explicit layering. In case you didn't see the same behavior that's been described in terms of the loaded image hiding the control buttons, you'll need to modify the XAML code. Note that the code available for download implements the solution correctly, so if you are following along with the sample code you'll need to modify the XAML in Window1.xaml. The incorrect version of this XAML is as follows:

<Grid>
    <Grid.RowDefinitions>

<RowDefinition Height="45" />
            <RowDefinition Height="215*" />
            <RowDefinition Height="40" />
        </Grid.RowDefinitions>
        <Label Margin="0,11,0,0" Name="Label1" HorizontalAlignment="Left" Width="80"
Height="23" VerticalAlignment="Top">Image Path:</Label>
        <TextBox Margin="81,13,92,0" Name="TextBox1" Height="21"
VerticalAlignment="Top" />
        <Button HorizontalAlignment="Right" Margin="0,11,9,0" Name="ButtonBrowse"
Width="75" Height="23" VerticalAlignment="Top">Images ...</Button>
        <Button Grid.Row="2" HorizontalAlignment="Right" Margin="0,0,15,8"
Name="ButtonNext" Width="75" Height="23" VerticalAlignment="Bottom">Next >></Button>
        <Button Grid.Row="2" HorizontalAlignment="Left" Margin="15,0,0,8"
Name="ButtonPrev" Width="75" Height="23" VerticalAlignment="Bottom"> Prev</Button>
        <Button Grid.Row="2" Margin="150,0,150,8" Name="ButtonLoad" Height="23"
VerticalAlignment="Bottom">View Images</Button>
        <Image Grid.Row="1" Grid.RowSpan="2" Margin="0,0,0,0" Name="Image1"
Stretch="Fill" />
    </Grid>

In the preceding XAML, the buttons are defined and loaded, and the image control isn't defined until later. As a result, the Image control is considered to be layered on top of the button controls. When the application starts, you might expect that Image control to immediately block the buttons, but it doesn't. That's because there is no image to display, so the Image control essentially stays out of the way, enabling the controls that would otherwise be behind it to both be displayed and receive input. WPF fully supports the concept of transparency, as demonstrated later in this chapter.

When there is something to display, the resulting image can block the same buttons that were used to load it, as shown in Figure 17-7. Because the image isn't part of the content for any of these buttons, none of the click events that would occur on the image at this point are raised to those buttons, so the buttons that are hidden don't respond. This is different behavior from what you get when you layer controls, and much closer to what a Windows Forms developer might expect. As a result, you need to be aware, just as with other user interfaces, of which order controls overlap in the same display area that's loaded.

Figure 17.7. Figure 17-7

Thus, everything you've done in the past, both with Windows Forms and ASP.NET, is still possible. On the surface, the WPF controls have more in common with existing programming models than might at first seem apparent.

Now that we have uttered heresy against this new UI paradigm, it's time to examine what is meant by a paradigm shift with the XAML model. As noted, it starts with a new set of classes and a new declarative language, but it continues with being able to have much finer control over your application's UI behavior.

Removing the Windows frame from your application is actually fairly easy to do, as you only need to set two properties on your form. The first is WindowStyle, which is set to "None"; the second is AllowTransparency, which is set to "True". You can accomplish that by adding the following line before the closing bracket of your window attributes:

WindowStyle="None" AllowsTransparency="True">

Once you've added this line to your XAML, run the application in the debugger. This is a good point to test not only what happens based on this change, but also the other changes you made to reduce the number of controls in your application. The result is shown in Figure 17-9. You probably notice that there are no longer any controls related to moving, resizing, closing, or maximizing your window. In fact, if you don't start the application within the Visual Studio debugger, you'll need to go to the Task Manager in order to end the process, as you haven't provided any way to end this application through the user interface.

Figure 17.9. Figure 17-9

In order to be able to skin this application, you need to provide some controls that implement many of the baseline window behaviors that most form developers take for granted. This isn't as hard as it might sound. The main challenge is to add a series of buttons for maximizing and restoring your application window, closing the application, and, of course, resizing the application. Because your designer wants to skin the application, you decide that the best way to handle the resize capability is with a single hotspot in the bottom right corner that represents the resize capability.

However, your first task is to provide a way to move the window. To do that you are going to add a rectangular area that maps to the top Grid.Row. This rectangle supports capturing the mouse down event and then responds if the user drags the window with the mouse button down. Because moving the window is essentially a mouse down and drag activity, as opposed to a click event, the Rectangle is a quick and easy way to implement this feature. It takes only a single line of XAML added as the first control in the grid:

<Rectangle Name="TitleBar" HorizontalAlignment="Stretch" Margin="0,0,0,0"
Stroke="Black" Fill="Green" VerticalAlignment="Stretch" />

Now, of course, you've filled the default rectangle with a beautiful green color to help with visibility, leaving the black border around the control. These two elements help you see where the rectangle is prior to taking this XAML into a designer and cleaning it up. Aside from this, however, having a control is only half the equation; the other half is detecting and responding to the drag event.

This is done with the following event handler, which is added using VB:

Private Sub Rectangle_MouseLeftButtonDown(ByVal sender As Object, _
                   ByVal e As System.Windows.Input.MouseButtonEventArgs) _
                   Handles TitleBar.MouseLeftButtonDown
    Me.DragMove()
End Sub

To recap, that's a single line of code in the handler calling the built-in method on the Window base class — DragMove. This method handles dragging the window to a new location. Right now the handler only looks for the dragging to occur from a control named TitleBar, but you could change this to something else or even change which control was called Titlebar.

Having resolved the first issue, you can move to the second: implementing the three buttons required for Minimize, Maximize, and Close. In each case the action required only occurs after a Click event. One of the unique characteristics of a button is that it detects a Click event, so it is the natural choice for implementing these actions. The buttons in this case should be images, so the first step is to create a few simple images.

Four image references have been added to the example project. Yes, these images are ugly, but the goal here isn't to create flashy design elements. You can literally spend days tweaking minor UI elements, which shouldn't be your focus. The focus here is on creating the elements that can be used in the UI. The color of the buttons, whether the Close button looks like the Windows icon, and so on are irrelevant at this point. What you care about here is providing a button with basic elements that a designer can later customize. As a rule, don't mix design and implementation.

The simplest way for an engineer to create graphics is with the world-famous Paint program. That's right, nothing fancy but reasonably meaningful. Create the four necessary .jpg files as 24 × 24 pixel images, and include an image for the resize handle for the window. Next, access the MyProject page and select the Resources tab. Then, select each of your .jpg files and add them as Image resources to the project, as shown in Figure 17-10.

Note that Visual Studio automatically places these items in the Resources folder for your project. Next, verify that in the properties for each file, the Build Action property is set to Resource. In order for these resources to be referenced from within your XAML, they need to be designated as resources, not just located in this folder. Now do a complete build of your project so the resources are compiled.

Figure 17.10. Figure 17-10

At this point you can move back to the XAML designer and add the three buttons for Minimize, Maximize, and Close. For your purposes, they should reside in the upper-right corner of the display and be around the same size as your new graphics. Drag a button onto the design surface and then edit the XAML to place it in the upper-right corner and size it to a height and width of 20 pixels. After doing this, one easy way to proceed is to simply copy that first button and paste two more buttons just like it into the XAML. Then all you need to do is change the button names and locations. Voilà — three buttons.

Of course, your goal is for these buttons to have images on them, so you need to add an Image control to the form and then move it so that it becomes the content for the first button. In this case, just bind the button to the borders of the button and then add a source to the button. Here, the source is the local reference to your .jpg resource, so in the case of ButtonClose, the source value is set to /Resources/20by_Exit.jpg. Add an Image control to the other two buttons and reference the associated resource in order to get the XAML here:

<Button Height="20" Width="20" HorizontalAlignment="Right" Margin="0,1,1,0"
                                Name="ButtonClose" VerticalAlignment="Top">
    <Image Margin="0,0,0,0" Name="Image2" Stretch="Fill"
               Source="/Resources/20by_Exit.JPG"/>
</Button>
<Button Height="20" Width="20" HorizontalAlignment="Right" Margin="0,1,25,0"
                                  Name="ButtonMax" VerticalAlignment="Top" >
      <Image Margin="0,0,0,0" Name="Image3" Stretch="Fill"
                                  Source="/Resources/20by_Max.JPG"/>
</Button>

<Button Height="20" Width="20" HorizontalAlignment="Right" Margin="0,1,47,0"
                                  Name="ButtonMin" VerticalAlignment="Top" >
      <Image Margin="0,0,0,0" Name="Image4" Stretch="Fill"
                                  Source="/Resources/20by_Min.JPG"/>
</Button>

At this point the basic XAML elements needed in order to implement a custom shell on this application are in place. Note that each button has a specific name: ButtonClose, ButtonMax, and ButtonMin. You'll need these, and the design can't change them because you'll use the button names to handle the Click event for each button. In each case, you need to carry out a simple action:

Private Sub ButtonMin_Click(ByVal sender As Object, _
                            ByVal e As RoutedEventArgs) _
                            Handles ButtonMin.Click
    Me.WindowState = WindowState.Minimized
End Sub

Private Sub ButtonMax_Click(ByVal sender As Object, _
                            ByVal e As RoutedEventArgs) _
                            Handles ButtonMax.Click
    If (Me.WindowState = WindowState.Maximized) Then
        Me.WindowState = WindowState.Normal
    Else
        Me.WindowState = WindowState.Maximized
    End If
End Sub

Private Sub ButtonClose_Click(ByVal sender As Object, _
                              ByVal e As RoutedEventArgs)
                              Handles ButtonClose.Click
    Me.Close()
End Sub

The code is fairly simple. After all, it's not as if the methods you need aren't still available; all you are doing is providing part of the plumbing that will enable your custom UI to reach these methods. Thus, to minimize the button's Click event, merely reset the window state to minimized. The real plumbing, however, was prebuilt for you as part of the way WPF layers controls. Keep in mind that when users click the minimize button, they are actually clicking on an image. WPF routes the Click event that occurred on that image.

When you hear about routed events and how powerful they are, remember that they are a capability built into the way that WPF layers and associates different controls. The routing mechanism in this case is referred to as bubbling because the event bubbles up to the parent; however, note that routed events can travel both up and down the control hierarchy.

For the ButtonMax event handler, the code is significantly more complex. Unlike minimizing a window, which has only one action when the button is pressed, the maximize button has two options. The first time it is pressed it takes the window from its current size and fills the display. If it is then pressed again, it needs to detect that the window has already been maximized and instead restore that original size. As a result, this event handler has an actual If statement that checks the current window state and then determines which value to assign.

Finally, the ButtonClose event handler has that one line of code that has been with VB developers pretty much since the beginning: Me.Close, telling the current window it's time to close. As noted, there isn't much magic here; the actual "magic" occurs with resizing.

Up until this point, changing the default window frame for a set of custom controls has been surprisingly easy. Now, however, if you are working on your own, you are about to hit a challenge. You need a control that will respond to the user's drag action and enable the user to drag the window frame while providing you with updates on that status.

There isn't a tool in the Visual Studio Toolbox for WPF that does this, but there are things such as splitter windows and other resizable controls that have this behavior. WPF was written in such a way that most of what you consider "controls" are actually an amalgamation of primitive single-feature controls. In this case, the primitive you are looking for is called a Thumb. The Thumb control is a WPF control, and it is located in the System.Windows.Controls.Primitives namespace.

Fortunately, you can directly reference this control from within your XAML, and once you have added it to your XAML, handling the events is just as simple as it is with your other custom UI elements. However, this control can't contain another control, and its default look is blank. For the moment, examine the XAML that is used to create an instance of this control on your form:

<Thumb Grid.Row="1" Cursor="ScrollAll" Name="ThumbResize" Height="20" Width="20"
HorizontalAlignment="Right" VerticalAlignment="Bottom" Margin="0,0,0,0" />

Note a few items of customization. Because the typical location to resize from in most UI models is the lower right corner, this control is placed in the lower right corner and aligned to the bottom and left edges of the bottom grid row. The control itself is sized to match the other buttons used to control the window's behavior. The name ThumbResize is used to indicate the control, and in this case the property Cursor is set. The Cursor property enables you to control the display of the mouse cursor when it moves over the control. There are several options in the enumeration of standard mouse cursors, and for this control arrows are displayed in every direction.

Before you change the default display any further, it makes sense to wire up an event handler. This enables you to test the control's behavior. Just as with the other event handlers, double-clicking on the control in the designer generates a default event handler for the control. In this case, the event to be handled is the DragDelta event. As the name implies, this event fires every time the potential size of the display area is changed. There are multiple ways to handle resizing. For this application, having the window redisplay as the user drags the mouse is feasible because the amount of time to update the display is short.

If that weren't the case, then you would want to override two additional events: DragStarted and DragOver. These events enable you to catch the window's start size and the final size based on the end of the user's action. You would then only resize the form in the DragOver event instead of in the DragDelta event. You would still need to override DragDelta because it is in this event that you monitor whether the window's minimum and/or maximum size constraints have been met:

Private Sub ThumbResize_DragDelta(ByVal sender As System.Object, _
                               ByVal e As Primitives.DragDeltaEventArgs) _
                               Handles ThumbResize.DragDelta
    Me.Height += e.VerticalChange
    If (Me.Height < Me.MinHeight) Then

Me.Height = Me.MinHeight
    End If
    Me.Width += e.HorizontalChange
    If (Me.Width < Me.MinWidth) Then
        Me.Width = Me.MinWidth
    End If
End Sub

The preceding block of code illustrates the code for this event handler. Notice that in this case the parameter e is specific to the DragDeltaEventArgs structure. This structure enables you to retrieve the current totals for both the vertical and horizontal change of the current drag location from the current window's frame.

This code enables you to see the visible window as the window is dragged because each time the event is fired, the Height and Width of the window are updated with the changes so that the window is resized. Note that this code handles checking the minimum height and width of your window. The code to check for the maximum size is similar. At this point, you can rerun the application to verify that the event is handled correctly and that as you drag the thumb, the application is resized.

Once you have the ThumbResize control working, the next step is to customize the display of this control. Unlike a button or other more advanced controls, this control won't allow you to associate it with an image or have content. As one of the primitive control types, you are limited to working with things such as the background color; and just assigning a color to this control really doesn't meet your needs. Thus, this is an excellent place to talk about another WPF feature: resources.

Typically, there comes a point where you want to include one or more resources with your application. A resource can be anything, including a static string, an image, a graphics element, and so on. In this case, you want to associate an image with the background of a control that would otherwise not support an image. Resources enable you to set up a more complex structure than just a color that can then be assigned to a control's property. For this simple example you'll create a simple application-level resource that uses an image brush, and then have your control reference this resource.

As noted in the introduction to XAML syntax, the definition for x:Key included the label object.Resources. The implication is that objects of different types can include resources. The scope of a resource, then, is defined by the scope of the object with which it is defined. For a resource that will span your application, you can in fact define that resource within your application XAML. Resources that are to be available within a given window are defined in the XAML file for that window. The following XAML demonstrates adding a resource to the application file of the sample application created earlier:

<Application x:Class="Application"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
          StartupUri="Window1.xaml">
    <Application.Resources>
        <ImageBrush x:Key="ResizeImage"
                                    ImageSource="/Resources/20by_Arrows.JPG">
        </ImageBrush>

</Application.Resources>
</Application>

Here, you are going to create a new ImageBrush. An image brush, as you would expect, accepts an image source and then it "paints" this image onto the surface where it is applied. In the XAML, notice that you assign an x:Key value. As far as XAML is concerned, this name is the identity of the resource. Once this has been assigned, other controls and objects within your XAML can reference this resource and apply it to an object or property. Thus, you need to add a reference to this resource to your definition of the ThumbResize control. This should result in a change to your XAML similar to this:

<Thumb Grid.Row="1" Cursor="ScrollAll" HorizontalAlignment="Right" Height="20"
Background="{StaticResource ResizeImage}" Name="ThumbResize"
Margin="0,0,0,0" Width="20" VerticalAlignment="Bottom" />

This change involves what is assigned to the background property of your Thumb control. As you look through XAML files, you will often see references to items such as StaticResources, and these can become fairly complex when you start to work with a tool such as Blend. However, this example should help you recognize what you are seeing when you look at more complex XAML files. You will also see references to dynamic resources, which are discussed later in this chapter in conjunction with dependency properties.

Resources can be referenced by several different controls and even other resources. However, resources aren't the only, or most maintainable, resource in all instances. Because a resource must be referenced within each object that uses it, it doesn't scale well across several dozen controls. In addition, during maintenance, each time someone edited a XAML file that applied resources to every control, they would also need to be careful to add that resource to any new controls. Fortunately, XAML borrows other resource types based on the basic idea of style sheets. WPF supports other types of resources, including templates and styles, which are discussed later in this chapter. Unlike styles and resources, templates are applied to all objects of the same type. Coverage of templates is beyond the scope of this chapter, but they work similarly to resources except that the settings they define are automatically applied to every control of a given type.

This juncture is an excellent point to test your application. When you start the application, you should see something similar to Figure 17-11. As noted earlier, at this point the application isn't exactly going to win a beauty contest (although the baby might). What you have achieved is a custom framework that enables you to literally treat an application UI as a blank slate, while still providing the standard Windows services that users have come to expect. This is important as you start to create applications that truly push the UI design envelope.

The answer is that every control is associated with one or more styles. As part of your work, you can create a style just as you created a resource. Styles can be assigned similarly to resources — that is, either by referencing them by name when assigning a new style to an instance of a control, or by creating a style that is associated with all instances of a given type. In either case, the Style property of a control is what is known as a dependency property.

When you hear the term dependency your initial reaction may be that this means the property has a dependency on some other item. However, in the context of WPF, a better way to think of the term dependency is that "it depends on who set that specific value in the object that defines that property." A dependency property isn't dependent on some external item; the property's value varies over time depending upon the last update to the property.

Going into the details of why this occurs is beyond the scope of this chapter. However, dependency properties are coupled with change notification logic, and play a significant role in things such as animation and 3-D layout. For the purposes of this chapter, it's only necessary to understand a few things about dependency properties. First, they reference resources and styles as dynamic resources, not static resources. Second, they are identified in the documentation of the WPF components. Finally, as stated already, the Style property is in fact a dependency property.

Styles essentially leverage the concept of resources. With a style you have the option of either referencing all objects of a common type and setting the default style for that control type or creating a custom style that is specific to those control instances that reference it. In short, styles provide a mechanism for you to apply a theme across an application and to override that theme in those specific instances where you want to. If another developer later adds new elements to your application, the default styles are automatically applied.

Styles are defined like resources; in fact, they are defined within the same section of your XAML file in which resources are defined. As with resources, when you define a style at the application level, the style can be applied across all of the windows in the application. Conversely, if a style is meant to target only the objects in a given window, page, or user control, then it makes sense to define them at that level.

Rather than provide a simple example of a style, in this case the goal is to understand where the hover effect for a standard button comes from, so the following code block provides the default style assigned to each control of type Button. As you might guess, this style was retrieved using Blend; it isn't available via Visual Studio. With Blend, you can request that it allow you to edit these default templates, and you can do so such that your changes will be used only on those controls for which you explicitly assign your custom style.

<Style x:Key="ButtonFocusVisual">
  <Setter Property="Control.Template">
    <Setter.Value>
      <ControlTemplate>
        <Rectangle SnapsToDevicePixels="true" Stroke="Black" StrokeDashArray="1 2"
StrokeThickness="1" Margin="2"/>
      </ControlTemplate>
    </Setter.Value>
  </Setter>
</Style>
<LinearGradientBrush x:Key="ButtonNormalBackground" EndPoint="0,1" StartPoint="0,0">
  <GradientStop Color="#F3F3F3" Offset="0"/>
  <GradientStop Color="#EBEBEB" Offset="0.5"/>
  <GradientStop Color="#DDDDDD" Offset="0.5"/>
  <GradientStop Color="#CDCDCD" Offset="1"/>
</LinearGradientBrush>
<SolidColorBrush x:Key="ButtonNormalBorder" Color="#FF707070"/>
<Style x:Key="ButtonStyle1" TargetType="{x:Type Button}">
  <Setter Property="FocusVisualStyle" Value="{StaticResource ButtonFocusVisual}"/>
  <Setter Property="Background" Value="{StaticResource ButtonNormalBackground}"/>
  <Setter Property="BorderBrush" Value="{StaticResource ButtonNormalBorder}"/>
  <Setter Property="BorderThickness" Value="1"/>
  <Setter Property="Foreground" Value="{DynamicResource {x:Static SystemColors.
ControlTextBrushKey}}"/>
  <Setter Property="HorizontalContentAlignment" Value="Center"/>
  <Setter Property="VerticalContentAlignment" Value="Center"/>
  <Setter Property="Padding" Value="1"/>
  <Setter Property="Template">
    <Setter.Value>
      <ControlTemplate TargetType="{x:Type Button}">

<Microsoft_Windows_Themes:ButtonChrome SnapsToDevicePixels="true"
x:Name="Chrome" Background="{TemplateBinding Background}" BorderBrush="{
TemplateBinding BorderBrush}" RenderDefaulted="{TemplateBinding IsDefaulted}"
RenderMouseOver="{TemplateBinding IsMouseOver}" RenderPressed="{TemplateBinding
IsPressed}">
          <ContentPresenter SnapsToDevicePixels="{TemplateBinding
SnapsToDevicePixels}" HorizontalAlignment="{TemplateBinding
HorizontalContentAlignment}" Margin="{TemplateBinding Padding}"
VerticalAlignment="{TemplateBinding VerticalContentAlignment}"
RecognizesAccessKey="True"/>
        </Microsoft_Windows_Themes:ButtonChrome>
        <ControlTemplate.Triggers>
          <Trigger Property="IsKeyboardFocused" Value="true">
            <Setter Property="RenderDefaulted" TargetName="Chrome" Value="true"/>
          </Trigger>
          <Trigger Property="ToggleButton.IsChecked" Value="true">
            <Setter Property="RenderPressed" TargetName="Chrome" Value="true"/>
          </Trigger>
          <Trigger Property="IsEnabled" Value="false">
            <Setter Property="Foreground" Value="#ADADAD"/>
          </Trigger>
        </ControlTemplate.Triggers>
      </ControlTemplate>
    </Setter.Value>
  </Setter>
</Style>

There are two lines of interest in the preceding code block. The first concerns the actual button style defined. Styles often reference other resources, and similar to early C compilers, references must be defined before they are actually referenced. Thus, the Style defined in the preceding code block is actually the last Style entry that starts thus:

<Style x:Key="ButtonStyle1" TargetType="{x:Type Button}">

This line indicates that this set of resources defines a style with the key ButtonStyle1. Because this style is defined with a key, it is not a default style applied to all controls of the target type. Styles always define a target type because different control types expect different specific values defined within all of the detailed elements of a style.

To have every control button use the same style, instead of providing a key for the style ButtonStyle1, you provide only the type definition. If at some point you want objects of different types to share certain characteristics, this can be done by defining a resource and then applying it to the style for each of the types. If these styles are then designated without a key, then they are by default applied to every object of that type.

All of that is great, but the goal is to find a way to remove the default highlight that occurs as you mouse over a button. The good news is that the hook that causes that behavior is in fact included in this file; the bad news is that it references a template that is then assigned to that behavior. The following line of XAML shows that the RenderMouseOver property is being associated with the template IsMouseOver:

RenderMouseOver="{TemplateBinding IsMouseOver}"

It is this template that causes the button to change its look to reflect this state. Thus, to have a button without this default behavior, you need to either define a new template or delete this line of XAML from your custom style.

You could, of course, take the preceding code block, make the necessary change, and paste it into your application's XAML. Certainly that will work if you also carry out the other steps that you need. However, long term, the preceding block of XAML is specific to controls of the type Button. Moreover, all of the preceding code was in fact generated from within Blend, so if you needed to customize the runtime behavior of another control type, you would have to find some way to generate the default style for that control.

This is where Blend becomes a requirement. Blend enables you to open your application directly. If, as assumed here, you are using Visual Studio 2008, then you can't open your projects using the current release of Blend. Blend 1.0 targets project files based on the Visual Studio 2005 format. In order to directly open your projects, you must have installed Service Pack 1 for Blend 1.0, which can open Visual Studio 2008 projects.

Normally when you open Blend, you can select any control in your application and generate the XAML for the default style. Blend will automatically integrate this style information into your XAML file, enabling you to proceed efficiently. However, in order to better understand styles, you are going to manually extract some style information generated by Blend for use within Visual Studio 2008.

Figure 17-13 shows the startup screen for Expression Blend. The only reason this screen is being shown is to highlight the fact that, of the three potential tabs in this window, the Samples tab is selected. This tab shows the list of samples that ship with Blend. These samples are not installed on disk with Blend. If you choose to open one of these samples, Blend generates the associated project at that time. What you need to know is that if you then modify anything in that project, even something as simple as adding a space to a XAML file, Blend will ask whether you want to create a copy of that sample on your local disk.

Figure 17.13. Figure 17-13

Once Blend opens, you are presented with what is probably best described as a rather dark and busy user interface. Fortunately, you can change the coloring. From the Tools menu, select Options. As shown in Figure 17-14, this opens the Options window. The first screen is the Theme setting. Changing this from Expression Dark to Expression Light enables you to see the interface in the same format for which the screens are being captured for this chapter. There don't seem to be any settings to reduce how much information the tool presents at once. In fact, this is one tool that, as these screenshots will demonstrate, isn't actually usable at 1024 × 768.

Figure 17.14. Figure 17-14

Once you've opened the tool, the next step is to open or create a project. Although you have a Visual Studio 2008 project, you'll want to create a new project to follow this demonstration on the default styling of a button. Use the File menu and select a new project. When the New Project dialog opens, you have the option to select a language, but because you only care about the XAML that will be generated, it doesn't matter which language or project name you select.

Once you have a new project, the main display area presents a clean white canvas, as shown in Figure 17-15. In order to add a button to this canvas, ensure that the Button control is selected in the toolbar. Unlike the Visual Studio toolbar, which lists each control, Blend groups the controls by category, from which you select a control. When you want to add that control to your display, you first click and hold the mouse button on that category to open the list of controls for that category. You then verify or select the control you wish to create.

Once you have selected the control, it displays above that category in the toolbar. You then take your mouse and draw that control onto your form. The Blend interface is not a drag and drop interface for adding controls. For this example, you'll select the button control and then draw that control onto your user interface.

Figure 17.15. Figure 17-15

Notice that unlike the Visual Studio editor that places both the design surface and the source XAML in the same display, Blend has room for only one of these surfaces. On the right-hand side of the display are the tabs that enable you to move between the design surface and the source XAML. You could edit a complete XAML file through this interface, but for now the only goal is to generate and retrieve the default style information associated with your control. Therefore, once you've added your button to this display, the next step is to ensure that it is selected on the design surface.

After you've added a button to your display surface, as shown in Figure 17-16, it is time to look for the XAML associated with the default style of that button. To generate this XAML, you need to first ensure that the control is selected. Next, as shown in Figure 17-16, open the Object menu, select the Edit Style menu option, and then select the Edit a Copy menu option.

Once you have selected this menu item, you'll be taken to the Create Style Resource dialog shown in Figure 17-17. This dialog enables you to customize the type of style declaration that is generated and to determine what level of scope this resource should have.

As Figure 17-17 shows, when you generate your style to include a key, it is specific to those controls that reference it. However, you can choose to generate a style that applies to all instances of a given control. The other option allows you to generate a resource that is defined at and within your application scope. The default is to create a resource at the level of the current window. Both of these options are acceptable; however, the designers of Blend foresaw that in the case of very large projects these files could start to become extremely large and unwieldy. As a result, Blend allows you to create a resource dictionary as part of your project.

Figure 17.16. Figure 17-16

Figure 17.17. Figure 17-17

In short, you can choose to create a new file that is referenced by either your application or window XAML file, and that contains and isolates your custom style and other resource definitions. The advantages of this method include not only a smaller file size for your key files, but the capability to separate the different resources into different files for scenarios in which multiple people are working on the same project. For example, one designer could work on customizing the style for buttons while another person is customizing the style of the drop-down lists.

For this example, call the new style NoHover and click OK. Once you complete this dialog, Blend generates the same style definition that was included earlier. You'll need to use the XAML tab, shown earlier in Figure 17-16, to switch to the source view; and just as you've seen previously when you created a resource manually, Blend adds all of the XAML for your default button behavior into this file.

Copy this text from Blend and return to Visual Studio. In Visual Studio, paste the text from Blend directly into the XAML for Window1.XAML. This places the new style definition into your project and immediately triggers an error. Typically when this is generated, and in fact in the sample project you just created in Blend, the Blend engine takes care of hooking your custom style into the project. The first step in this process is adding a reference to the classes that define that style. Thus, you need to add a new reference to your project. Figure 17-18 shows the MyProject References page with a newly added reference.

Figure 17.18. Figure 17-18

The reference at the project level to the PresentationFramework.Aero libraries allows you various source files to reference this library. However, there is still one more step. You need to reference this library from within the XAML for Window1. Go to the definition of the window and its attributes at the top of your XAML file and add another xmlns, also known as an XML namespace declaration:

<Window x:Class="Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Microsoft_Windows_Themes="clr-namespace:Microsoft.Windows.Themes;
assembly=PresentationFramework.Aero"
    Title="ProVB_WPF" Height="335" Width="415" Name="MainWindow"
    WindowStyle="None" AllowsTransparency="True">

The highlighted line is the line that needs to be added to your source file. Once this line is added you'll find that the XAML errors that occurred when you pasted the new style definition into your window go away. This is the same reference that you added to your project, but in this case you are defining for the XML compiler where to find things such as the definition for Chrome. As with the project reference, Blend typically handles this automatically for you.

At this point there is only one more manual step in this process. Although you've added a new style to your project, you haven't referenced that style anywhere. For the purpose of this version, you are just going to add that style definition to the ButtonBrowse definition. Doing so works just like other resources you've referenced, but in this case the assignment to the Style property is for a dynamic resource:

<Button Style="{DynamicResource NoHover}" HorizontalAlignment="Stretch"
Margin="0,0,130,2" Name="ButtonBrowse" >Images Folder</Button>

You should then be able to compile and run the application and get a result similar to what is shown in Figure 17-19. Notice that many of the graphics have been updated to be less stark, and include some basic color gradients. I did this by closing Visual Studio and reopening the project in Blend. Just as with Visual Studio, you can open the solution file for ProVB_WPF_Step_3. Blend displays your project on the right-hand side, in a window just like the Visual Studio Solution Explorer, although the tab is named Project. Open your Window1.xaml file. On the right-hand side you'll see the tree that represents the controls used in your XAML.

Figure 17.19. Figure 17-19

Selecting, for example, the button, you want to then select the Properties tab, which is located next to your Project tab. Once you have opened this, you have access to many of the display properties of your control. In the case of ButtonBrowse, I modified its background brush to be transparent. I did this by first selecting the Brushes section and then selecting the background. I then made certain that a solid brush was selected from the row of buttons so that I would see the color selector. There are four color options: Red, Green, and Blue (RGB) are self-explanatory. The remaining value is the A channel, which reflects transparency. Setting this to 100 means that you can't see through that item; setting this to 0 means that a given value is invisible.

I set the button background to be transparent, and then repositioned it to be centered better in the title bar. Next, I selected that rectangle called Title Bar to edit its display properties. I went to the brushes section of the Properties again, but this time I selected a gradient brush for the background. This results in the color display, but below it you have what looks similar to the ruler in Word. The ruler in Word is where you manage page elements such as page borders and tabs, and setting gradient colors works similarly.

On the left side of the toolbar is a little tag; if you drag this tag to the right, the default black color continues and the gradient section of the display decreases. Similarly, on the right-hand side of the display is a tag is associated with white. To change the default colors, you select that tag and then edit the color resources, just as you edit the A channel for transparency, only this time you focus on the RGB values. However, a gradient brush isn't limited to two color tags; in the ProVB_WPF_Step_3 project, the left corner of the title bar is green and the right side is blue.

To replicate this requires four tags on your gradient bar, and to add those tags you simply click on the bar. Just like adding tabs in Word, you can easily define additional color transition points. By defining the two inner tags as white and adjusting their position near the edges of the ButtonBrowse display, you can create a white background for the button while creating a gradient on either side of the title bar.

For the three control buttons, I first created a blue gradient background for each button. However, because the buttons actually display images, this background isn't visible, so I expanded each button and selected the image associated with the display of that button. Each image has an opacity property. The opacity property is another way of referencing the A channel for the color system, and by reducing the opacity from 100 percent to 50 percent, the blue background for each button is visible. The result is a version of the application that matches the final code in ProVB_WPF_Step_3 and looks similar to what is shown in Figure 17-19.

The next step is to separate out the custom window framework that was the focus of the ProVB_WPF_Step_2 project created earlier in this chapter. This can act as a base set of application classes that can be reused across multiple different applications. You can leverage the main application in Window1 just for managing your window and take the logic associated with its contents for displaying images and move that into a user control.

As for the specific controls available in WPF, you've seen in this chapter that several are available, although even those like the button that seem familiar may not work as expected. The fact is that WPF controls need to fit a different paradigm than the old Windows Forms model. In that model, a control could be associated with data, and in some cases undergo minor customization to its look and feel. Under WPF, the concept of a grid is used. It isn't, however, similar to the old Windows Forms DataGridView in any way. The WPF grid is a much more generic grid that enables you to truly customize almost everything about its behavior.

Part of the goal of WPF is to make it immaterial which environment your application will work in, Web or desktop. For example, consider a couple of the bottom-layer elements. The one used most in this chapter is the Window control. As demonstrated in the first ProVB_WPF example, a window includes a frame and a title in addition to its content area. You might want to apply a layout grid or a panel — for example, a stack panel — within this content area. Conversely, you could take a different tack and place a user control within this window. In fact, in most cases this is the recommended path because of the other low-level WPF element — the Page.

A Page control is, of course, the base UI element for a Web application, so it's easy to see how this paradigm of the content area can support the layering of two different user-interface implementations. Once you have defined the base elements of your user interface you can leverage user controls, which are equally happy on the desktop or in the browser. Of course, creating applications that flexible is a bit more challenging, unless you are leveraging services. In other words, instead of targeting the file system, you would target a service that might be local or remote and that would be focused on the appropriate file system. Then the application is running on a local computer. It can encapsulate the pages in a Window control; and when hosted in a browser, it can use those same user controls within the framework of a Page.

Aside from some standard user interface controls, the WPF Toolbox contains nearly all of the controls that you can find in every other Windows-based user interface model, such as tabs, toolbars, tooltips, text boxes, drop downs, expanders, and so on. It should also be noted that the WPF namespace consists of several graphics, ink, and even data and data-bound controls.

Accordingly, the key to working with WPF is taking these basic controls and using WPF user control projects to create the building blocks that you will then use to create your custom user interfaces. If the example in this chapter demonstrated anything, it is how time consuming making changes to the XAML can be.