Microsoft Visual Basic 2013 Step by Step: Using XAML Styles

After completing this chapter, you will be able to

• Understand how XAML styles are used to build attractive-looking user interfaces.

• Define reusable styles in the App.xaml project file.

• Reference new styles by using the Style property for controls on the page

• Build new styles from existing styles using inheritance and the BasedOn property

This chapter continues your exploration of XAML markup by investigating how XAML styles are used to format controls with a consistent and attractive appearance across the user interface. So far in this book, you’ve created controls individually and customized them with a variety of property settings. However, you can also define new, reusable styles in a project that will help you format objects automatically. This sophisticated design feature allows you to save time and build a consistent and professional-looking user interface in Windows Store apps.

You’ll begin by creating a new Windows Store application, and then you’ll define a new style resource in the App.xaml file, so that it can be referenced throughout the project. You’ll define the new style with XAML markup, identifying the control that you want to configure with the TargetType property. You’ll then assign specific properties to the style by defining one or more Setter elements for the control. Finally, you’ll open the MainPage.xaml file and create XAML Toolbox controls on the page that will take advantage of the new styles you’ve defined. You’ll also extend your expertise by using the BasedOn property, which allows you to build new styles from existing styles. In object-oriented programming terminology, this mechanism is known as inheritance—you assign the features and properties of one resource to another resource.

Introduction to XAML styles

Most programmers dislike reinventing the wheel, or completing the same basic task over and over again. If there is a simple way to automate a bit of formatting or programming, software developers will usually go out of their way to do it, especially if automating the task helps them save time and avoid potential coding mistakes down the road.

XAML styles are one useful coding mechanism that allows Visual Studio developers to automate the construction of the user interface. XAML styles enable the Windows programmer to set various properties for controls and then reuse those settings to build a consistent visual appearance across the application. Each XAML style that you create is designed for a particular XAML Toolbox control. For example, you might create a new style named FramedPhoto that is meant to assign a collection of standard display properties to one or more Image controls in the user interface of a Windows Store app. Of course, you could assign these properties individually to each Image control that you wanted to look a particular way, but a simpler method would be to create a new style resource that could be assigned to all of the Image controls. Such an approach would have the advantage of saving you development time, but it would also produce more consistent formatting results across the objects in the user interface. When you use styles, you are less likely to forget a crucial property setting when you are formatting a collection of similar objects.

An additional advantage of custom styles is that you can make broad formatting changes in an existing project very quickly. When you modify an existing style resource in App.xaml or a resource dictionary associated with the project, all of the objects that reference that particular style will automatically reflect the change.

Where did StandardStyles.xaml go?

In Visual Studio 2012, a style resource dictionary named StandardStyles.xaml was automatically created for each new Windows Store project and stored in the Common folder in Solution Explorer. This file contained a vast collection of predefined styles that you could use in your programs, and it was possible to modify the file to customize the basic styles that Microsoft supplied. StandardStyles.xaml was integral to Windows Store app development in Visual Studio 2012 because it defined user interface elements that closely followed Microsoft’s design principles for Windows 8.

The following screen shot shows the default reference to StandardStyles.xaml in a Visual Studio 2012 project designed for the Windows Store. This reference appears in the App.xaml file in the project. I mention it now because you might still see this reference in projects that have been migrated to Visual Studio 2013 from Visual Studio 2012.

However, in Visual Studio 2013, StandardStyles.xaml file is no longer created automatically in a Windows Store project, and in the App.xaml file the entire <Application.Resources> section has been deleted. You also won’t see the Common folder in Solution Explorer that once held StandardStyles.xaml. Instead, the Windows Store platform automatically supports Windows 8.1 control styling, and it is no longer necessary to edit StandardStyles.xaml directly. You can reference predefined styles by using the StaticResource extension in XAML markup when you work with controls.

Creating new XAML styles

When you are ready to create your own XAML styles in a project, you have some options about where you place the markup that defines the styles. First, you can create a style for an individual page by adding the style definition to the <Page.Resources> section of the page’s XAML file. If your Windows Store app has only one page in it, this file will be named MainPage.xaml by default. (You’ve been using MainPage.xaml throughout this book to define the user interface for your app.) However, if you define new styles in this way, they can be referenced only by objects located on the page where you defined the style. This type of declaration is called a page-level resource definition.

Second, you can create your new styles in the <Application.Resources> section of your project’s App.xaml file. This is a more flexible approach; if you define styles in this way, they will be available for use throughout the project—that is, in all of the pages that are part of your Windows Store app. So far in this book, you’ve created demonstration programs that use just one page to process input and display information. However, more sophisticated “real world” programs often utilize several pages to manage input and output. For this reason, it is best to get comfortable defining new styles in the App.xaml file.

Third, you can also create new styles in a stand-alone XAML resource dictionary file that is shared across multiple Windows Store apps. This is a useful programming strategy if you find that you are always creating controls on the page that have the same base characteristics and if you find it bothersome to define custom styles in the App.xaml file of each new project that you start. In fact, you can create more than one resource dictionary file in Visual Studio, and you can assign multiple resource dictionary files to your applications.

To add a resource dictionary file to your project, open the project in Visual Studio, click the New Item command on the Project menu, and double-click the Resource Dictionary template in the Add New Item dialog box. Define your new styles in this template, and add it to other projects that you want to incorporate the custom styles.

Considering the scope of a style

As your Visual Studio projects begin to fill up with custom styles, a new question might suddenly occur to you: How do the various style definitions coexist in a project if the styles are defined in more than one file location?

The answer to this question depends on where the new styles were defined and the way in which they are used. That is, issues related to the accessibility context or scope of the new styles. Page-level styles are available only to the objects that exist on the same page where the styles are defined. However, if styles with the same name are defined in both the project-wide App.xaml file and on an individual page like MainPage.xaml, the local style on MainPage.xaml overrides (or takes priority over) the resource in App.xaml. Likewise, a style defined in App.xaml overrides a style of the same name in a resource dictionary file that has been added to the project.

Thinking about the scope of styles, variables, namespaces, and other definitions in a Windows Store app is important to do because there are often times when the same names are used. You’ll learn more about these issues in Part III of this book, “Visual Basic programming techniques.”

Sample markup for a new XAML style

How is a new style definition created?

Styles should be defined in the XAML file that gives the style resource the broadest scope without forcing you to maintain files that you would not otherwise be using. As noted earlier in this chapter, most of the time you should be defining styles in App.xaml or a resource dictionary. Inside the files, you define each new style between <Style> and </Style> tags, and you must define the styles after any resources that contain information pertinent to the styles. (For example, it is important to define new styles after any MergedDictionary entries that you see, because new styles often make use of standard styles that are included in these entries.)

For a page-level definition in a file such as MainPage.xaml, place the style under the <Page.Resources> tag. For a project-level definition in the App.xaml file, place the style under the <Application.Resources> tag. In a resource dictionary file, place the style under the <ResourceDictionary> tag.

In the style definition itself, you use the x:Key property to give the style a unique name, and you use the TargetType property to identify the control that you are customizing or styling. You then assign individual property settings using one or more Setter properties. Each Setter assignment must include a property name and a value that is defined using XAML markup. These property assignments must be compatible with the control you are styling. If you assign a property or value to a style that does not match the control definition you are referencing, an error will occur.

The following XAML markup sample shows the elements of a new style definition in an App.xaml file, which will make the style resource available through the application. The new style is named FramedPhoto, and it appears in a new <Application.Resources> section in the file. The new style resource has been formatted in bold type.

The style will set the Height, Width, and Stretch properties for any Image control in the project that references the style. Note that I am including some of the boilerplate markup in App.xaml so that you can see where the new style is located. In particular, it is necessary to place the new style definition between the <Application.Resources> and </Application.Resources> tags. The style itself is defined between the <Style> and </Style> tags.

<Application
    x:Class="XAML_Style_Practice.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:XAML_Style_Practice">
    <Application.Resources>
        <Style x:Key="FramedPhoto" TargetType="Image">
            <Setter Property="Height" Value="240"/>
            <Setter Property="Width" Value="320"/>
            <Setter Property="Stretch" Value="Fill"/>
        </Style>
    </Application.Resources>
</Application>

Referencing a style

To use or reference a new style in the XAML markup for an object in the user interface, you use the Style property.

The following markup shows how you might reference the new FramedPhoto style defined in the preceding section. There are four lines highlighted in bold type (lines 2-5) that I want to direct your attention to—these define an image object on the page that will be styled by the FramedPhoto style resource. Notice in particular how the FramePhoto name is used along with the StaticResource markup extension, quotation marks, and a pair of curly brackets.

<Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
        <Image Style="{StaticResource FramedPhoto}"
               HorizontalAlignment="Left"
               Margin="522,176,0,0"
               VerticalAlignment="Top"/>
        <Image HorizontalAlignment="Left"
               Margin="346,75,0,0"
               VerticalAlignment="Top"/>
</Grid>

What results does this XAML markup produce? Even though the new style is being used to set some of the properties for the first image object on the page (Height, Width, and Stretch), several remaining properties are set by markup associated with the image object’s own definition (HorizontalAlignment, Margin, and VerticalAlignment). As a result, the image object is defined with a height of 240 pixels, a width of 320 pixels, a Stretch property set to Fill, a horizontal alignment set to Left, and so on. Because none of the property settings overlap, there are no scope or override issues, but you can see how such overlaps might occur. As I noted earlier, Visual Studio will resolve them by giving priority to the style with the most local scope.

There is also a second image object defined in this sample markup. Note that this image has no particular style associated with it, so it will not be formatted by the FramedPhoto style. I defined two image objects in this sample simply to clarify that you don’t need to style every object the same way if you don’t want to.

Using explicit and implicit styles

When you define a new style as a resource in your project, there are actually two ways to work with the style in XAML markup. First, you can define and use the new style explicitly, as shown earlier in this chapter, by identifying a specific x:Key property for the style and then referencing the style by name when you format controls on the page.

Alternatively, you can define and use styles implicitly (that is, without giving the style a specific name), by omitting the x:Key property when you define the style and then letting Visual Studio assign the style automatically to every control that matches the style’s TargetType. Implicit styling is the best way to get all of the objects of a particular type to be styled the same way in a project. It works because Visual Studio takes the TargetType (control name) from the style definition and assigns it to the x:Key property for the style.

If implicit styling sounds a little confusing, here’s a simple example that explains how implicit styling works and why it might be useful. Consider the following page-level definition for a new XAML style that formats a text box control. At the top of the sample is a style definition between the <Page.Resources> and </Page.Resources> tags that defines the new style. It sets the Background property of a TextBox control to the color green and changes the control’s FontSize property to 24 point. Notice that there is no x:Key property, but TargetType is set to TextBox, making the style implicit for all of the text box objects in the project that do not have a specific style name. (If a text box object does have a specific style associated with it, it would be exempt from the implicit styling.)

<Page.Resources>
        <Style TargetType="TextBox">
            <Setter Property="Background" Value="Green"/>
            <Setter Property="FontSize" Value="24"/>
        </Style>
</Page.Resources>
<Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
        <TextBox
            HorizontalAlignment="Left"
            Height="136"
            Margin="346,75,0,0"
            Text="Green Text Box"
            Width="263" />
</Grid>

The bottom portion of the XAML code defines a text box object within the main grid on the page. A collection of properties are set by the markup; in addition to these, Visual Studio uses the implicit style definition to format the background color of the text box to green and to set the font size to 24-point. This is the recommended strategy you should follow when using implicit styles—define a handful of essential properties with the implicit style, and then further customize individual objects in the project with additional styles that are needed. You should become familiar with both explicit and implicit styling strategies to managing the look and feel of objects in your user interface.