Silverlight：《Pro Silverlight5》读书笔记 之 XAML

XAML

Properties and Events in XAML

Simple Properties and Type Converters

To bridge the gap between string values and nonstring properties, the XAML parser needs to perform a conversion. The conversion is performed by type converters, a basic piece of infrastructure that’s borrowed from the full .NET Framework.

Essentially, a type converter has one role in life—it provides utility methods that can convert a specific .NET data type to and from any other .NET type, such as a string representation in this case. The XAML parser follows two steps to find a type converter:

1. It examines the property declaration, looking for a TypeConverter attribute. (If present, the TypeConverter attribute indicates what class can perform the conversion.) For example, when you use a property such as Foreground, .NET checks the declaration of the Foreground property.
2. If there’s no TypeConverter attribute on the property declaration, the XAML parser checks the class declaration of the corresponding data type. For example, the Foreground property uses a Brush object. The Brush class (and its derivatives) uses the BrushConverter because the Brush class is decorated with the TypeConverter(typeof(BrushConverter)) attribute declaration.

Some classes define a content property, which allows you to provide the property value between the start and end tags. For example, the Button class designates Content as its content property, meaning this markup:

 <Button>Click Me!</Button>

is equivalent to this:

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

Complex Properties

XAML provides another option: property-element syntax. With property-element syntax, you add a child element with a name in the form Parent.PropertyName. For example, the Grid has a Background property that allows you to supply a brush that’s used to paint the area behind the elements. If you want to use a complex brush—one more advanced than a solid color fill—you’ll need to add a child tag named Grid.Background, as shown here:

 <UserControl x:Class="EightBall.Page"
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
     <Grid x:Name="grid1">
         <Grid.Background>
             <LinearGradientBrush>
                 <LinearGradientBrush.GradientStops>
                     <GradientStop Offset="0.00" Color="Yellow" />
                     <GradientStop Offset="0.50" Color="White" />
                     <GradientStop Offset="1.00" Color="Purple" />
                 </LinearGradientBrush.GradientStops>
             </LinearGradientBrush>
         </Grid.Background>
     </Grid>
 </UserControl>

Attached Properties

Attached properties always use a two-part name in this form: DefiningType.PropertyName. This two-part naming syntax allows the XAML parser to distinguish between a normal property and an attached property.

 <UserControl x:Class="EightBall.Page"
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
     <Grid x:Name="grid1">
         <Grid.RowDefinitions>
             <RowDefinition Height="*" />
             <RowDefinition Height="Auto" />
             <RowDefinition Height="*" />
         </Grid.RowDefinitions>

         <TextBox x:Name="txtQuestion"
             Grid.Row="0"
             Text="[Place question here.]">
         </TextBox>

         <Button x:Name="cmdAnswer"
             Grid.Row="1"
             Content="Ask the Eight Ball">
         </Button>

         <TextBox x:Name="txtAnswer"
             Grid.Row="2"
             Text="[Answer will appear here.]">
         </TextBox>
     </Grid>
 </UserControl>

Attached properties aren’t really properties at all. They’re actually translated into method calls. The XAML parser calls the static method that has this form: DefiningType.SetPropertyName(). For example, in the previous XAML snippet, the defining type is the Grid class, and the property is Row, so the parser calls Grid.SetRow().

When calling SetPropertyName(), the parser passes two parameters: the object that’s being modified and the property value that’s specified. For example, when you set the Grid.Row property on the TextBox control, the XAML parser executes this code:

 Grid.SetRow(txtQuestion, );

This pattern (calling a static method of the defining type) is a convenience that conceals what’s really taking place. To the casual eye, this code implies that the row number is stored in the Grid object. However, the row number is actually stored in the object that it applies to—in this case, the TextBox object.

This sleight of hand works because the TextBox derives from the DependencyObject base class, as do all Silverlight elements. The DependencyObject is designed to store a virtually unlimited collection of dependency properties (and attached properties are one type of dependency property).

In fact, the Grid.SetRow() method is actually a shortcut that’s equivalent to calling the DependencyObject.SetValue() method, as shown here:

 txtQuestion.SetValue(Grid.RowProperty, );

Nesting Elements

XAML allows each element to decide how it deals with nested elements. This interaction is mediated through one of three mechanisms that are evaluated in this order:

1. If the parent implements IList<T>, the parser calls the IList<T>.Add() method and passes in the child.
2. If the parent implements IDictionary<T>, the parser calls IDictionary<T>.Add() and passes in the child. When using a dictionary collection, you must also set the x:Key attribute to give a key name to each item.
3. If the parent is decorated with the ContentProperty attribute, the parser uses the child to set that property.

Some properties might support more than one type of collection. In this case, you need to add a tag that specifies the collection class, like this:

         <Grid.Background>
             <LinearGradientBrush>
                 <LinearGradientBrush.GradientStops>
                     <GradientStopCollection>
                         <GradientStop Offset="0.00" Color="Yellow" />
                         <GradientStop Offset="0.50" Color="White" />
                         <GradientStop Offset="1.00" Color="Purple" />
                     </GradientStopCollection>
                 </LinearGradientBrush.GradientStops>
             </LinearGradientBrush>
         </Grid.Background>

Nested content doesn’t always indicate a collection. For example, consider the Grid element, which contains several other elements:

 <UserControl x:Class="EightBall.Page"
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
     <Grid x:Name="grid1">
         <Grid.RowDefinitions>
             <RowDefinition Height="*" />
             <RowDefinition Height="Auto" />
             <RowDefinition Height="*" />
         </Grid.RowDefinitions>

         <TextBox x:Name="txtQuestion"
             Grid.Row="0"
             Text="[Place question here.]">
         </TextBox>

         <Button x:Name="cmdAnswer"
             Grid.Row="1"
             Content="Ask the Eight Ball">
         </Button>

         <TextBox x:Name="txtAnswer"
             Grid.Row="2"
             Text="[Answer will appear here.]">
         </TextBox>
     </Grid>
 </UserControl>

These nested tags don’t correspond to complex properties, because they don’t include the period. Furthermore, the Grid control isn’t a collection and so it doesn’t implement IList or IDictionary. What the Grid does support is the ContentProperty attribute, which indicates the property that should receive any nested content. Technically, the ContentProperty attribute is applied to the Panel class, from which the Grid derives, and looks like this:

 [ContentPropertyAttribute("Children")]
 public abstract class Panel : FrameworkElement

This indicates that any nested elements should be used to set the Children property. The XAML parser treats the content property differently depending on whether it’s a collection property (in which case it implements the IList or IDictionary interface). Because the Panel.Children property returns a UIElementCollection and because UIElementCollection implements IList, the parser uses the IList.Add() method to add nested content to the grid.

Events

In many situations, you’ll use attributes to set properties and attach event handlers on the same element. Silverlight always follows the same sequence: first it sets the Name property (if set), then it attaches any event handlers, and lastly it sets the properties. This means that any event handlers that respond to property changes will fire when the property is set for the first time.

XAML Resources

Silverlight includes a resource system that integrates closely with XAML. Using resources, you can do the following:

1. Create nonvisual objects: This is useful if other elements use these objects. For example, you could create a data object as a resource and then use data binding to display its information in several elements.
2. Reuse objects: Once you define a resource, several elements can draw on it. For example, you can define a single brush that’s used to color in several shapes. Later in this book, you’ll use resources to define styles and templates that are reused among elements.
3. Centralize details: Sometimes, it’s easier to pull frequently changed information into one place (a resources section) rather than scatter it through a complex markup file, where it’s more difficult to track down and change.

The Resources Collection

Every element includes a Resources property, which stores a dictionary collection of resources. The resources collection can hold any type of object, indexed by string.

Although every element includes the Resources property, the most common way to define resources is at the page level. That’s because every element has access to the resources in its own resource collection and the resources in all of its parents’ resource collections. So if you define a resource in the page, all the elements on the page can use it.

         <LinearGradientBrush x:Key="BackgroundBrush">
             <LinearGradientBrush.GradientStops>
                 <GradientStop Offset="0.00" Color="Yellow" />
                 <GradientStop Offset="0.50" Color="White" />
                 <GradientStop Offset="1.00" Color="Purple" />
             </LinearGradientBrush.GradientStops>
         </LinearGradientBrush>
     </UserControl.Resources>

To use a resource in your XAML markup, you need a way to refer to it. This is accomplished using a markup extension—a specialized type of syntax that sets a property in a nonstandard way. Markup extensions extend the XAML language and can be recognized by their curly braces. To use a resource, you use a markup extension named StaticResource:

 <Grid x:Name="grid1" Background="{StaticResource BackgroundBrush}">

The Hierarchy of Resources

Every element has its own resource collection, and Silverlight performs a recursive search up your element tree to find the resource you want.

Order is important when defining a resource in markup. The rule of thumb is that a resource must appear before you refer to it in your markup.

Interestingly, resource names can be reused as long as you don’t use the same resource name more than once in the same collection. In this case, Silverlight uses the resource it finds first. This allows you to define a resource in your application resources collection and then selectively override it with a replacement in some pages with a replacement.

Accessing Resources in Code

 LinearGradientBrush brush = (LinearGradientBrush)this.Resources["ButtonFace"];

However, there’s one limitation. Because Silverlight doesn’t support dynamic resources, you aren’t allowed to change the resource reference. That means you can’t replace a resource with a new object. Here’s an example of code that breaks this rule and will generate a runtime error:

 SolidColorBrush brush = new SolidColorBrush(Colors.Yellow);
 this.Resources["ButtonFace"] = brush;

Rather than dig through the Resources collection to find the object you want, you can give your resource a name by adding the Name attribute. You can then access it directly by name in your code. However, you can’t set both a name and a key on the same object, and the StaticResource markup extension recognizes keys only. Thus, if you create a named resource, you won’t be able to use it in your markup with a StaticResource reference. For that reason, it’s more common to use keys.

Organizing Resources with Resource Dictionaries

If you want to share resources between multiple projects or just improve the organization of a complex, resource-laden project, you can create a resource dictionary. A resource dictionary is simply a XAML document that does nothing but store a set of resources.

 <ResourceDictionary
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

 </ResourceDictionary>

To use a resource dictionary, you need to merge it into a resource collection somewhere in your application. You could do this in a specific page, but it’s more common to merge it into the resources collection for the application, as shown here:

 <Application xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 x:Class="SilverlightApplication1.App">
     <Application.Resources>
         <ResourceDictionary>
             <ResourceDictionary.MergedDictionaries>
                 <ResourceDictionary Source="ElementBrushes.xaml" />
             </ResourceDictionary.MergedDictionaries>
         </ResourceDictionary>
     </Application.Resources>
 </Application>

One reason to use resource dictionaries is to define the styles for application skins that you can apply dynamically to your controls. Another reason is to store content that needs to be localized (such as error message strings).

Element-to-Element Binding

One-Way Binding

 <Slider x:Name="sliderFontSize" Margin="3"
 Minimum="1" Maximum="40" Value="10">
 </Slider>

 <TextBlock Margin="10" Text="Simple Text" x:Name="lblSampleText"
 FontSize="{Binding ElementName=sliderFontSize, Path=Value}" >
 </TextBlock>

Data binding expressions use a XAML markup extension (and hence have curly braces). You begin with the word Binding, followed by any constructor arguments  and then a list of the properties you want to set by name—in this case, ElementName and Path. ElementName indicates the source element. Path indicates the property in the source element. Thus, this binding expression copies the value from the Slider.Value property to the TextBlock.FontSize property.

Tip:The Path can point to a property of a property (for example, FontFamily.Source) or an indexer used by a property (for example, Content.Children[0]). You can also refer to an attached property (a property that’s defined in another class but applied to the bound element) by wrapping the property name in parentheses. For example, if you’re binding to an element that’s placed in a Grid, the path (Grid.Row) retrieves the row number where you’ve placed it.

备注：在单向绑定中，如果用代码修改了绑定目标的属性值，目标属性的绑定就会消失（得查查为啥这样设计）。

Two-Way Binding

Interestingly, there’s a way to force values to flow in both directions: from the source to the target and from the target to the source. The trick is to set the Mode property of the Binding to TwoWay.