As a convenience, if all of the properties can be set on a shared base class, like Control in our example, we can promote the class prefix into the TargetType attribute and remove it from the name of the property (see Example 8-6).

<Style x:Key="CellTextStyle" TargetType="{x:Type Control}">
  <Setter Property="FontSize" Value="32pt" />
  <Setter Property="FontWeight" Value="Bold" />
</Style>

When providing a TargetType attribute, you can only set properties available on that type. If you’d like to expand to a greater set of properties down the inheritance tree, you can do so by using a more derived type (see Example 8-7).

<Style x:Key="CellTextStyle" TargetType="{x:Type Button}">
  <!-- IsCancel is a Button-specific property -->
  <Setter Property="IsCancel" Value="False" />
  <Setter Property="FontSize" Value="32pt" />
  <Setter Property="FontWeight" Value="Bold" />
</Style>

In this case, the IsCancel property is available only on Button, so to set it, we need to switch the target type attribute for the style.

In addition to saving you from typing out the name of the class prefix for every property name, the TargetType attribute will also confirm that all classes that have the style applied are an instance of that type (or derived type). That means that if we leave TargetType set to Control, we can apply it to a Button element, but not to a TextBlock element, as the former derives ultimately from Control but the latter does not.

However, if we’d like to define a style that contains properties not shared by every element to which we’d like to apply them, we can do that by dropping the TargetType and putting back the property prefix, as shown in Example 8-8.

<Style x:Key="CellTextStyle">
  <Setter Property="TextElement.FontSize" Value="32pt" />
  <Setter Property="Button.IsCancel" Value="False" />
</Style>
...
<!-- has an IsCancel property -->
<Button Style="{StaticResource CellTextStyle}" ... />

<!-- does *not* have an IsCancel property -->
<TextBlock Style="{StaticResource CellTextStyle}" ... />

In Example 8-8, we’ve added the Button.IsCancel property to the CellTextStyle and applied it to the Button element, which has this property, and the TextBlock element, which doesn’t. This is OK. At runtime, WPF will apply the dependency properties and the elements themselves will ignore those values that don’t apply to them.^[51]

Getting back to our sample, we can use the CellTextStyle on the Buttons to show nice Xs and Os, and on a TextBlock in a new row to show whose turn it is (see Example 8-9).

<Window.Resources>
  <Style x:Key="CellTextStyle">
    <Setter Property="Control.FontSize" Value="32pt" />
    <Setter Property="Control.FontWeight" Value="Bold" />
  </Style>
</Window.Resources>
<Grid Background="Black">
  <Grid.RowDefinitions>
    <RowDefinition />
    <RowDefinition />
    <RowDefinition />
    <RowDefinition Height="Auto" />
  </Grid.RowDefinitions>
  <Grid.ColumnDefinitions>
    <ColumnDefinition />
    <ColumnDefinition />
    <ColumnDefinition />
  </Grid.ColumnDefinitions>
  <Button Style="{StaticResource CellTextStyle}" ... />
  ...
  <TextBlock
    Style="{StaticResource CellTextStyle}"
    Foreground="White"
    Grid.Row="3"
    Grid.ColumnSpan="3"
    Name="statusTextBlock" />
</Grid>
</Window>

With our new text block in place, we can inform the next player of her turn by updating the CurrentPlayer property setter:

string CurrentPlayer {
  get { return this.currentPlayer; }
  set {
    this.currentPlayer = value;
    this.statusTextBlock.Text =
      "It's your turn, " + this.currentPlayer;
  }
}

This reuse of the style across controls of different types gives us a consistent look in the application, as shown in Figure 8-3.

Figure 8-3. A tic-tac-toe game with style

One thing you’ll notice is that the status text in Figure 8-3 is white, whereas the text in the buttons is black. Because black is the default text color, if we want the status text to show up against a black background, we have to change the color to something else, hence the need to set the Foreground property to white on the TextBlock. Setting per-instance properties works just fine in combination with a style, and you can combine the two techniques of setting property values as you see fit.

Further, if we wanted to override a style property on a specific instance, we can do so by setting the property on the instance (see Example 8-10).

<Style x:Key="CellTextStyle">
  <Setter Property="TextElement.FontSize" Value="32pt" />
  <Setter Property="TextElement.FontWeight" Value="Bold" />
</Style>
...
<TextBlock
  Style="{StaticResource CellTextStyle}"
  FontWeight="Normal" ... />

In Example 8-10, the TextBlock instance property setting of FontWeight takes precedence over the style property setting of FontWeight.

In addition to the abilities to reuse and override existing styles, you can also extend a style, adding new properties or overriding existing ones (see Example 8-11).

<Style x:Key="CellTextStyle">
  <Setter Property="Control.FontSize" Value="32pt" />
  <Setter Property="Control.FontWeight" Value="Bold" />
</Style>
<Style x:Key="StatusTextStyle" BasedOn="{StaticResource CellTextStyle}">
  <Setter Property="TextBlock.FontWeight" Value="Normal" />
  <Setter Property="TextBlock.Foreground" Value="White" />
  <Setter Property="TextBlock.HorizontalAlignment" Value="Center" />
</Style>

The BasedOn style attribute is used to designate the style being extended. In Example 8-11, the StatusTextStyle style gets all of the CellTextStyle property setters, overrides the FontWeight, and adds setters for Foreground and HorizontalAlignment. Our current use of styles causes our tic-tac-toe game to look like Figure 8-4.

Figure 8-4. A tic-tac-toe game with more style

Our application so far is looking pretty good, but we can do better.

Once a style has a name, it’s easily available from our code. For example, we might decide that we’d like each player to have his own style:

<Style x:Key="XStyle" BasedOn="{StaticResource CellTextStyle}">
  <Setter Property="Control.Foreground" Value="Red" />
</Style>
<Style x:Key="OStyle" BasedOn="{StaticResource CellTextStyle}">
  <Setter Property="Control.Foreground" Value="Green" />
</Style>

In this case, applying named styles to each button in XAML at compile time won’t do the trick, because we want to set the style based on the content, and in this application, the content changes when a button is clicked at runtime. However, nothing requires us to set the Style property of a control statically; we can set it programmatically as well, as we do in Example 8-12.

public partial class Window1 : Window {
  ...
  void cell_Click(object sender, RoutedEventArgs e) {
    Button button = (Button)sender;
    ...
  // Set button content
    button.Content = this.CurrentPlayer;
    ...
    if( this.CurrentPlayer == "X" ) {
      button.Style = (Style)FindResource("XStyle");
      this.CurrentPlayer == "O";
    }
    else {
      button.Style = (Style)FindResource("OStyle");
      this.CurrentPlayer == "X";
    }
    ...
  }
  ...
}

In Setting Styles Programmatically, whenever the player clicks, in addition to setting the button’s content, we pull a named style out of the window’s resources with the FindResource method and use that to set the button’s style, as shown in Figure 8-5.

Figure 8-5. Setting styles programmatically based on an object’s content (Figure F-7)

Notice that the Xs and Os are colored according to the named player styles. In this particular case (and in many other cases, too), data triggers should be preferred to setting styles programmatically, but we’ll get to that later.

When you define a style with only a TargetType, that style will be applied only to elements of that exact type and not to derived types. For example, if you’ve got a single style that you’d like to apply to both the CheckBox and the RadioButton types, you might think to create a style for their common base type (ToggleButton), as in Example 8-17.

<Window ...>
  <Window.Resources>
    <!-- this isn't going to be applied to RadioButton or CheckBox -->
    <Style TargetType="ToggleButton">
      <Setter Property="FontSize" Value="32" />
    </Style>
</Window.Resources>
  <StackPanel Margin="5">
    <TextBlock FontSize="32">two toggle buttons:</TextBlock>
    <CheckBox>my checkbox</CheckBox>
    <RadioButton>my radio button</RadioButton>
  </StackPanel>
</Window>

As Figure 8-6 shows, the style associated with the ToggleButton type will not be applied to either the radio button or the checkbox.

Figure 8-6. Element-typed styles aren’t applied to derived types

This limitation keeps styles from leaking to unknown derived types. However, if you’d like to centralize the settings for a style on a base type and apply it to known derived types, you can do so with a little extra work (see Example 8-18).

<Window ...>
  <Window.Resources>
    <Style x:Key="toggleButtonStyle" TargetType="ToggleButton">
      <Setter Property="FontSize" Value="32" />
    </Style>
    <Style TargetType="RadioButton"
      BasedOn="{StaticResource toggleButtonStyle}" />
    <Style TargetType="CheckBox"
      BasedOn="{StaticResource toggleButtonStyle}" />
  </Window.Resources>
  ...
</Window>

In Example 8-18, we gave our toggle button style a key and then used it with the BasedOn property of our element-typed styles for RadioButton and CheckBox, as shown in Figure 8-7.

Figure 8-7. You can mix TargetType and BasedOn for good effect

Using this technique, we’re able to define element-typed styles and reuse settings across known derived types.

As you already know from Chapter 7, WPF allows you to define a data template, which is a tree of elements to expand in a particular context. We use data templates to provide an application with the capability to render nonvisual objects (see Example 8-21).

<Window ... xmlns:local="clr-namespace:TicTacToe">
  <Window.Resources>
    ...
    <Style TargetType="{x:Type Button}">
      <Setter Property="HorizontalContentAlignment" Value="Stretch" />
      <Setter Property="VerticalContentAlignment" Value="Stretch" />
      <Setter Property="Padding" Value="8" />
    </Style>
    <DataTemplate DataType="{x:Type local:PlayerMove}">
      <Grid>
        <TextBlock
          Text="{Binding Path=PlayerName}"
          FontSize ="32pt"
          FontWeight="Bold"
          VerticalAlignment="Center"
          HorizontalAlignment="Center" />
        <TextBlock
          Text="{Binding Path=MoveNumber}"
          FontSize="16pt"
          FontStyle="Italic"
          VerticalAlignment="Bottom"
          HorizontalAlignment="Right" />
      </Grid>
    </DataTemplate>
  </Window.Resources>
  ...
</Window>

Using the XAML mapping syntax described in Chapter 1, we’ve mapped the PlayerMove type into the XAML with the xmlns attribute, which we’ve used as the data type of the data template. Now, when a WPF element that uses the content model sees a PlayerMove object, like the content of all of our buttons, the data template will be expanded.^[52] In our case, the template consists of a grid to arrange two text blocks, one showing the player name in the middle of the button and one showing the move number in the bottom right, along with some other settings to make things pretty. In addition, we’ve changed our button style to give the grid the entire space of the content area, less some padding around the edge (otherwise, things get a little cramped). Figure 8-9 shows the result.

Figure 8-9. Showing objects of a custom type using data templates and styles

Just as it’s a good idea to take “magic numbers” out of your code, pulling them out and giving them names for easy maintenance, it’s a good idea to move groups of settings into styles,^[53] as shown in Example 8-22.

<Window.Resources>
  ...
  <Style x:Key="CellTextStyle" TargetType="{x:Type TextBlock}">
    <Setter Property="FontSize" Value="32pt" />
    <Setter Property="FontWeight" Value="Bold" />
    <Setter Property="VerticalAlignment" Value="Center" />
    <Setter Property="HorizontalAlignment" Value="Center" />
  </Style>
 <Style x:Key="MoveNumberStyle" TargetType="{x:Type TextBlock}">
    <Setter Property="FontSize" Value="16pt" />
    <Setter Property="FontStyle" Value="Italic" />
    <Setter Property="VerticalAlignment" Value="Bottom" />
    <Setter Property="HorizontalAlignment" Value="Right" />
  </Style>
  <DataTemplate DataType="{x:Type local:PlayerMove}">
    <Grid>
      <TextBlock
        Text="{Binding Path=PlayerName}"
        Style="{StaticResource CellTextStyle}" />
      <TextBlock
        Text="{Binding Path=MoveNumber}"
        Style="{StaticResource MoveNumberStyle}" />
    </Grid>
  </DataTemplate>
</Window.Resources>

As nice as Figure 8-9 is, the interaction is kind of boring given the capabilities of WPF. Let’s see what we can do with style properties as the application is used.

The simplest form of a trigger is a property trigger, which watches for a dependency property on the element to have a certain value. For example, we might want to set the tool tip over a button if neither player has yet chosen it for a move. We can do so by watching for the Content property to have a value of null,^[54] as shown in Example 8-23.

<Style TargetType="{x:Type Button}">
  ...
  <Style.Triggers>
    <Trigger Property="Content" Value="{x:Null}" >
      <Setter Property="ToolTip" Value="click to move here" />
    </Trigger>
  </Style.Triggers>
</Style>

Triggers are grouped together under the Style.Triggers element. In this case, we’ve added a Trigger element to the button style. When the Content property of our button is null, the ToolTip property of the button will be set to “click to move here,” as shown in Figure 8-10.

Figure 8-10. A property trigger in action (Figure F-8)

There’s no need to worry about setting a property back when the trigger is no longer true (e.g., watching for Content to be non-null). The WPF dependency property system watches for the property trigger to become inactive and reverts the property to the previous value.

You can set property triggers to watch any of the dependency properties on the control to which your style is targeted and to set any of the dependency properties on the control while the condition is true. In fact, you can use a single trigger to set multiple properties if you like.

Although you can set as many properties as you like in a property trigger, there can be more than one trigger in a style. When grouped together under the Style.Triggers element, multiple triggers act independently of one another.

For example, we can update our example so that if the content is null on one of our buttons, it’ll have one tool tip, but if the button has focus (the Tab and arrow keys move focus around), it’ll have another tool tip, as shown in Example 8-24.

<Style TargetType="{x:Type Button}">
  ...
  <Style.Triggers>
    <Trigger Property="Content" Value="{x:Null}" >
      <Setter Property="ToolTip" Value="click to move here" />
    </Trigger>
    <Trigger Property="IsFocused" Value="True" >
      <Setter Property="ToolTip" Value="click or spacebar to move here" />
    </Trigger>
</Style>

Figure 8-11 shows the result of one cell having both focus and the mouse hovering.

Figure 8-11. Multiple property triggers in action (Figure F-9)

If multiple triggers set the same property, the last one wins. For example, in Figure 8-11, because the button has no content and focus, the tool tip will be the one associated with the keyboard focus because the trigger for the IsFocused trigger is last in the list.

One thing you may have noticed about Example 8-24 is that it checks only for keyboard focus. However, just checking for the focus isn’t enough; we also need to check whether the button already has content. If you’d like to check more than one property before a trigger condition is activated, you can combine multiple conditions with a multiple condition property trigger, as shown in Example 8-25.

<Style TargetType="{x:Type Button}">
  ...
  <Style.Triggers>
    <Trigger Property="Content" Value="{x:Null}" >
      <Setter Property="ToolTip" Value="click to move here" />
    </Trigger>
    <MultiTrigger>
      <MultiTrigger.Conditions>
        <Condition Property="IsFocused" Value="True" />
        <Condition Property="Content" Value="{x:Null}" />
      </MultiTrigger.Conditions>
      <Setter Property="ToolTip" Value="click or spacebar to move here" />
    </MultiTrigger>
  </Style.Triggers>
</Style>

Multicondition property triggers check all of the properties’ values to be set as specified, not just one of them. Here, we’re watching for both keyboard focus and the content to be null, reflecting the game logic that new moves can happen only in empty cells.

Property triggers are great for noticing when the user is interacting with an element displaying your program’s state. However, we’d also like to be able to notice when the program’s state itself changes—such as when a particular player makes a move—and update our style settings accordingly. For that, we have data triggers.

Unlike property triggers, which check only WPF dependency properties, data triggers can check any old thing to which you can bind (e.g., a CLR object property, an XPath statement, etc.). Whereas property triggers are generally used to check WPF visual element properties, data triggers are normally used to check the properties of nonvisual objects used as content, like our PlayerMove objects (see Example 8-26).

<Window.Resources>
  <Style TargetType="{x:Type Button}">
    ...
  </Style>
  <Style x:Key="CellTextStyle" TargetType="{x:Type TextBlock}">
    ...
    <Style.Triggers>
      <DataTrigger Binding="{Binding Path=PlayerName}" Value="X">
        <Setter Property="Foreground" Value="Red" />
      </DataTrigger>
      <DataTrigger Binding="{Binding Path=PlayerName}" Value="O">
        <Setter Property="Foreground" Value="Green" />
      </DataTrigger>
    </Style.Triggers>
  </Style>
  <Style x:Key="MoveNumberStyle" TargetType="{x:Type TextBlock}">
    ...
  </Style>
  ...
  <DataTemplate DataType="{x:Type l:PlayerMove}">
    <Grid>
      <TextBlock
        TextContent="{Binding Path=PlayerName}"
        Style="{StaticResource CellTextStyle}" />
      <TextBlock
        TextContent="{Binding Path=MoveNumber}"
        Style="{StaticResource MoveNumberStyle}" />
    </Grid>
  </DataTemplate>
</Window.Resources>

DataTrigger elements go under the Style.Triggers element just like property triggers, and also just like property triggers, more than one of them can be active at any one time. Whereas a property trigger operates on the properties of the visual elements displaying the content, a data trigger operates on the content itself. In our case, the content of each cell is a PlayerMove object. In both of the data triggers, we’re binding to the PlayerName property. If the value is “X,” we’re setting the foreground to red, and if it’s “O,” we’re setting it to green.

We haven’t had per-player colors since moving to data templates after setting styles programmatically in Figure 8-5, but data triggers bring that feature right back, along with all of the other features we’ve been building up, as shown in Figure 8-12.

Figure 8-12. Data triggers in action (Figure F-10)

Unlike property triggers, which rely on the change notification of dependency properties, data triggers can also use an implementation of the standard property change notification patterns built into .NET and discussed in Chapter 6 (e.g., INotifyPropertyChanged). Even our simple class needs to raise such notifications as the IsPartOfWin property changes (it’s set when a win is detected). If you’re using data triggers, chances are that you’ll need to expose notifications from your data classes.

One other especially handy feature of data triggers is that there’s no need for an explicit check for null content. If the content is null, the trigger condition is automatically false, which is why the application isn’t crashing trying to dereference a null PlayerMove to get to the PlayerName property.

Just as we can combine property triggers into “and” conditions using the MultiTrigger element, we can combine data triggers using the MultiDataTrigger element. For example, if we wanted to watch for winning moves and match the move number to the color of the player that won, we’d need two multicondition data triggers, one for each player, as shown in Example 8-27.

<Style x:Key="MoveNumberStyle" TargetType="{x:Type TextBlock}">
  ...
  <Style.Triggers>
    <MultiDataTrigger>
      <MultiDataTrigger.Conditions>
        <Condition Binding="{Binding Path=PlayerName}" Value="X" />
        <Condition Binding="{Binding Path=IsPartOfWin}" Value="True" />
      </MultiDataTrigger.Conditions>
      <Setter Property="BitmapEffect">
        <Setter.Value>
          <OuterGlowBitmapEffect GlowColor="Red" GlowSize="10" />
        </Setter.Value>
      </Setter>
    </MultiDataTrigger>

    <MultiDataTrigger>
      <MultiDataTrigger.Conditions>
        <Condition Binding="{Binding Path=PlayerName}" Value="O" />
        <Condition Binding="{Binding Path=IsPartOfWin}" Value="True" />
      </MultiDataTrigger.Conditions>
      <Setter Property="BitmapEffect">
        <Setter.Value>
          <OuterGlowBitmapEffect GlowColor="Green" GlowSize="10" />
        </Setter.Value>
      </Setter>
    </MultiDataTrigger>
  </Style.Triggers>
</Style>

Here we’re setting a glow around the winning move numbers to make the crucial moves clear.^[55]Figure 8-13 shows the results after a win.

Figure 8-13. The winner aglow with pride (Figure F-11)

The multicondition data trigger in Example 8-27 sets the move number to match the color of the winner to connote a cause for celebration, but you can use multicondition data triggers for celebrations of your own kinds. Also, I didn’t show it in this example, but because data triggers support CLR property change notifications as well as dependency property change notifications, they are very handy inside the Triggers element of a data template.

Whereas property triggers check for values on dependency properties and data triggers check for values on CLR properties, event triggers watch for events. When an event (like a Click event) happens, an event trigger responds by raising an animation-related event. Although animation is interesting enough to deserve its own chapter (Chapter 16), Example 8-28 shows a simple animation that will transition a button from transparent to opaque over two seconds when it’s clicked.

<Style TargetType="{x:Type Button}">
  ...
  <Style.Triggers>
    ...
    <EventTrigger RoutedEvent="Click">
      <EventTrigger.Actions>
        <BeginStoryboard>
          <Storyboard>
            <DoubleAnimation Storyboard.TargetProperty="Opacity"
                             From="0" To="1" Duration="0:0:2" />
          </Storyboard>
        </BeginStoryboard>
      </EventTrigger.Actions>
    </EventTrigger>
  </Style.Triggers>
</Style>

To add an animation to a style requires two things. The first is an event trigger with the name of the event that caused the trigger to fire (the Click event, in our case). The second is a storyboard, which is a grouping for animations. When the Click event happens, we begin the storyboard. Our storyboard happens to contain one animation, which animates the Opacity property on the button from fully transparent to fully opaque. Figure 8-14 shows the results of clicking the button in the upper left about halfway through the fade-in animation.

Figure 8-14. The event trigger and our fade-in animation (Figure F-12)

Event triggers let you trigger animations when events happen. Property and data triggers let you set properties when properties change, but they also let you start or stop animations (discussed in Chapter 16). Both types of triggers let you add a degree of interactivity to your applications in a wonderfully declarative way with little or no code.