In Example 5-12, the TextBlock instance property setting of FontWeight take precedence over the style property settings of FontWeight.
Inheriting Style Properties
To complete the object-oriented triumvirate of reuse, override, and inheritance, you can inherit a style from a base style, adding new properties or overriding existing ones, as in Example 5-13.
TheBasedOnstyle attribute is used to designate the base style. In Example 5-13, theStatusTextStyle style inherits all of theCellTextStyleproperty setters, overrides theFontWeight, and adds setters forForeground andHorizontalAlignment. Notice that theHorizontalAlignmentproperty uses aTextBlockprefix; this is becauseTextElementdoesn’t have aHorizontalAlignmentproperty.
Our current use of styles causes our tic-tac-toe game to look like Figure 5-4.
Figure 5-4.A tic-tac-toe game with more style
Our application so far is pretty good, especially with the thin font weight on the status text, 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 their own style. In this case, using named styles in XAML at compile time won’t do the trick, since we want to set the style based on the content, which isn’t known until runtime. However, there’s nothing that requires us to set the Style property of a control statically; we can set it programmatically as well, as we do in Example 5-14.
In Example 5-14, whenever the player clicks, in addition to setting the button’s content, we pull a named style out of the window’s resources and use that to set the button’s style. This assumes a pair of named styles defined in the window’s scope, as in Example 5-15.
With these styles in place and the code to set the button style along with content, we get Figure 5-5.
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 (discussed in “Data Triggers,” later in this chapter) should be preferred to setting styles programmatically, but you never know when you’re going to have to jam.
As with all XAML constructs, you are free to create styles themselves programmatically. Appendix A is a good introduction on how to think about going back and forth between XAML and code.
Figure 5-5. Setting styles programmatically based on an object's content (Color Plate 9)
Named styles are useful when you’ve got a set of properties to be applied to specific elements. However, if you’d like to apply a style uniformly to all instances of a certain type of element, set the TargetType without a Key, as in Example 5-16.
Key , as in Example 5-16.TargetTypewithout a Key , as in Example 5-16.Named styles are useful when you’ve got a set of properties to be applied to specific elements. However, if you’d like to apply a style uniformly to all instances of a certain type of element, set the TargetType without a Key, as in Example 5-16.
In Example 5-16, we’ve got two styles, one with aTargetTypeofButton and noKey and another with aTargetType ofTextBlockand noKey. Both work in the same way; when an instance ofButtonorTextBlockis created without an explicitStyle attribute setting, it uses the style that matches the target type of the style to the type of the control. Our element-typed styles return our game to looking like Figure 5-4 again.
Element-typed styles are handy whenever you’d like all instances of a certain element to share a look, depending on the scope. For example, we’ve scoped the styles in our sample thus far at the top-level Window in Example 5-17.
Example 5-17. Styles scoped to the Window
<!-- Window1.xaml --> <Window ...> <!-- every Button or TextBlock in the Window is affected --> <Window.Resources> <Style TargetType="{x:Type Button}">...</Style> <Style TargetType="{x:Type TextBlock}">...</Style> </Window.Resources> ... </Window>
However, you may want to reduce the scope of an element-typed style. In our sample, it would work just as well to scope the styles inside the grid so that only buttons and text blocks in the grid are affected, as in Example 5-18.
Example 5-18. Styles scoped below the Window
<!-- Window1.xaml --> <Window ...> <Grid ...> <!-- only Buttons or TextBlocks in the Grid are affected --> <Grid.Resources> <Style TargetType="{x:Type Button}">...</Style> <Style TargetType="{x:Type TextBlock}">... </Style> </Grid.Resources> ... </Grid> <!-- Buttons and TextBlocks outside the Grid are unaffected --> ... </Window>
Or, if you want to make your styles have greater reach in your project, you can put them into the application scope, as in Example 5-19.
Example 5-19. Styles scoped to the application
<!-- MyApp.xaml --> <Application ...> <!-- every Button or TextBlock in the Application is affected --> <Application.Resources> <Style TargetType="{x:Type Button}">...</Style> <Style TargetType="{x:Type TextBlock}">...</Style> </Application.Resources> </Application>
In general it’s useful to understand the scoping rules of element-typed styles so you can judge their effect on the various pieces of your WPF object model. Chapter 6 discusses resource scoping of all kinds, including styles, in more detail.
Named versus element-typed styles
When choosing between styles set by style name or by element type, one of our reviewers said that in his experience, once you get beyond 10 styles based on element type, it was too hard to keep track of where a particular control was getting its style from. This is one reason that I’m a big fan of named styles.
To me, a style is a semantic tag that will be applied to content in one place and awarded a visual representation in another. As simple as our tic-tac-toe sample is, we’ve already got two styles, one for the status text and one for the move cell; before we’re done, we’re going to have more. The major differentiating factor is going to be the kind of data we’ll be showing in these elements, not the type of the element holding the data. In fact, we’ll have several styles assigned toTextBoxcontrols, which negates the use of type-based styles anyway, even for this simple application.
Let’s imagine that we wanted to implement a version of tic-tac-toe that’s more fun to play (that’s an important feature in most games). For example, one variant of tic-tac-toe allows players to have only three of their pieces on at any one time, dropping the first move off when the fourth move is played, dropping the second move when the fifth is played, and so on. To implement this variant, we need to keep track of the sequence of moves, which we can do with a PlayerMove class, as in Example 5-20.
Example 5-20. A custom type suitable for tracking tic-tac-toe moves
namespace TicTacToe { public class PlayerMove { private string playerName; public string PlayerName { get { return playerName; } set { playerName = value; } }
private int moveNumber; public int MoveNumber { get { return moveNumber; } set { moveNumber = value; } }
public PlayerMove(string playerName, int moveNumber) { this.playerName = playerName; this.moveNumber = moveNumber; } } }
Now, instead of using a simple string for each of the button object’s content, we’ll use an instance of PlayerMove in Example 5-21. Figure 5-6 shows the brilliance of such a change.
Example 5-21. Adding the PlayerMove as Button content
namespace TicTacToe { public partial class Window1 : Window { ... int moveNumber;
Figure 5-6. PlayerMove objects displayed without any special instructions
As you’ll recall from Chapter 4, what’s happening in Figure 5-6 is that the button doesn’t have enough information to render a PlayerMove object, but we can fix that with a data template.
Please check back tomorrow for the continuation of this article.
Styles and Control Templates
