On the Button class, Width and Height are simple value types. WPF converts the string value 100 to a double implicitly. However, many properties on controls are not simple value types. Some properties are objects that have lots of properties themselves, which could also be complex types. In our example, the Background property on Button is of type Brush. In the XAML, we are able to simply say Blue and it works.

There are many places in XAML where commonly used types, such as SolidColorBrush, can be represented by a simple string value that WPF just knows how to handle. In the case of SolidColorBrush, you can provide any named color, as found on the System.Windows.Media.Colors class, or you can provide a hexadecimal representation of the color similar to those you would use in HTML or CSS. Both of the following XAML snippets are equivalent:

<Button Background="#FF0000FF" />
<Button Background="Blue" />

In some situations, however, this shorthand is not sufficient for telling WPF what you want. In those cases we can use property element syntax. Property element syntax is an alternative syntax used for providing values for complex types. Instead of setting the Background property using an attribute, we can use a child element. The following snippet demonstrates using this alternative syntax for setting the background to blue:

    <Button>
        <Button.Background>
            <SolidColorBrush Color="Blue" />
        </Button.Background>
    </Button>

The child element is referred to as a property element. Property elements take the form of <ClassName.PropertyName />. That is, the first part of the element’s name is the class name, followed by a dot, followed by the property’s name. The content of the child element is the value we want to set. When using a property element, we need to be more explicit and tell WPF that we want the value to be an instance of SolidColorBrush with the Color property set to blue. This syntax can become very verbose, but in many situations it is the only way to provide the exact value that you desire.

It’s preferable to use the shorthand when possible. Succinct markup is easier to read and it makes the intention of the XAML clearer.

Many of the WPF controls that you will encounter have a property named Content. Content is a special property. In Listing 2.1, we set the Content of a Button to a string value, Click Me. However, you can also set the Content property implicitly using a child element. For example, the following XAML elements are equivalent:

<Button Content="Click Me" />
<Button>Click Me</Button>

Both buttons will be rendered the same in WPF. What’s exciting is that Content is actually of type object. That means that we can make a button’s content much more than just a simple string. For example, perhaps we want to draw a yellow circle inside our button. You could use the following XAML:

    <Button>
        <Ellipse Width="24"
                 Height="24"
                 Fill="Yellow" />
    </Button>

You can always set the Content property explicitly, too:

    <Button>
        <Button.Content>
            <Ellipse Width="24"
                     Height="24"
                     Fill="Yellow" />
            </Button.Content>
    </Button>

However, doing so is more verbose and does nothing to improve the readability or maintainability of your code. Furthermore, the convention of setting the Content property implicitly is almost universally adopted.

If you go back to Listing 2.1 one more time, you will notice that our Button element is actually the value for the Page.Content property.

Sometimes we need to specify values in our markup that are either difficult to express in XAML or outside the scope of the XAML processor. XAML has a feature called markup extensions and it allows us to handle these awkward situations.

For example, suppose we have a specific color we want to use as the background for several buttons in a WPF application. We could set the Background property on each of the buttons to use the same color, but it would become tedious if we ever needed to change that color. With WPF, we can store the color with a lookup key in an application’s resources. (We’ll discuss this concept in depth in Hour 14, “Resources and Styles.”) Now we can set the background of the buttons to the color we stored in the resources. If we want to change the color, we need do so in only one place. That’s a lovely scenario, but how would we handle this in XAML? We would use a markup extension.

In the preceding scenario, the XAML with the markup extension might look like this:

        <Button Background="{StaticResource ResourceKey=myColor}"
                Content="Click Me" />

Markup extensions are indentified by the presence of curly brackets ({}). The first word in the markup extension tells WPF what kind of extension it is. The name of the extension is optionally followed by a set of named parameters. In this case, the extension is for retrieving a shared resource from a library of resources. The name of the extension is StaticResource, and we provide a value of myColor for the ResourceKey parameter. Many extensions have a default parameter. You don’t have to explicitly reference a default parameter. You are allowed to omit the parameter name and the equal sign. For example, we could restate the snippet without ResourceKey=:

       <Button Background="{StaticResource myColor}"
               Content="Click Me" />

ResourceKey is the default parameter for StaticResource.

In some cases, you will have more than one parameter. If you do, you must separate name/value pairs with commas. The general pattern is this:

{ExtensionName Param1=Value1, Param2=Value2, Param3=Value3}

The most frequent mistake in dealing with markup extensions is to include quotation marks around the values. You are not allowed to have quotation marks between the curly brackets. This confuses the parser. It also means that parameter values cannot have whitespace.

Many markup extensions are built in to WPF, and you can even write your own (however, it is not common to do so).

We’ll cover specific extensions as they become relevant throughout the book; however, Table 2.1 has a very brief summary of the most significant extensions. Don’t be too concerned about understanding these extensions right now; they will make sense in context.