Section 3.3. Attributes
3.3. AttributesAttributes are the XML representation of the properties of an element's corresponding CLR class. The Width attribute of the XAML Button element corresponds directly to the Width property of the System.Windows.Button class. To show the correlation between XAML and CLR classes, Examples 3-7 and 3-8 declare a Button instance and its attributes in both XAML and C#. Example 3-7. Button declared in XAML
Example 3-8. Button declared in C#
As with the XAML tags for elements, attributes are spelled exactly the same as their corresponding CLR class properties. (Width = Width, Content = Content . . . You get the picture.) There are two types of XAML attributes. The first, dependency properties, are public static read-only fields on CLR classes that are derived from DependencyProperty and have declared CLR accessor methods. In other words, the value of dependency properties can be dependent on (hence the name) other variables in CLR classes and, therefore, can only be accessed with a public get or set accessor method to be evaluated properly. Dependency properties are like stock certificates. The stock certificate represents a value (money), but the actual amount of money it is worth (its value) is determined by external calculations and can change at nearly any time. To determine the value of your stock certificate, you must consult the stock exchange and do some multiplication. Dependency properties can also be based on external resources and often rely on calculations to determine their value. Dependency property values are determined from a number of different places. The WPF property system searches for the value from the following places in this order:
These attributes provide support for value expressions, property invalidation, default values, inheritance, data binding, animation, and styling. The property system is complex, so WPF provides simple get and set accessor methods to manipulate these attributes. The second type of attribute supported in XAML is the common language runtime property . Common language runtime properties are standard read/write CLR class properties that can be accessed directly and do not require get or set accessor methods, although they generally have them. Both dependency properties and common runtime properties are accessed in XAML using the same techniques. The difference between them is important only when you are using more advanced techniques, such as defining styles or triggers that act upon a specific attribute. Some attributes of elements must reference a dependency property, so you need to know which attributes are dependency properties and which are not. Regardless of their underlying types, all XAML attributes can be assigned in one of two ways. They can be assigned inline, as part of the element declaration, or they can be explicitly declared as nested elements within the element being described. As a general rule, complex attributes must be declared explicitly, while simple attributes can be defined inline, as shown in Example 3-9. Simple attributes are those whose data types are primitives, such as String, Integer, and Double. Enumerations are also declared inline, using a String representation of the name of the enumerated value. All inline attribute declarations must be enclosed in double quotes, regardless of the underlying data type of the property being described. You don't have to enclose attributes of type String in two sets of quotes. String is sort of the exception to the rule, because it is, after all, already a String. Example 3-9. Inline declaration of a simple attribute
Complex attributes are defined as a CLR class or are of type struct. They are declared explicitly, as shown in Example 3-10. In this example, GeometryDrawing has two complex attributes: Pen and Geometry. Neither attribute can be specified using abbreviated syntax, so it is necessary to explicitly declare them. The exception to this rule is the specification of child elements, which are declared by using standard XML mechanisms without the name of the attribute. This is illustrated in Example 3-10, in which two instances of EllipseGeometry are implicitly declared as children of GeometryGroup. It is not necessary to specify child elements as a complex attribute by name. Elements nested between the opening and closing tags of an element are assumed to be the children of that element and are automatically added to the appropriate container property according to the CLR class, usually the Children or InternalChildren property of the parent element. Example 3-10. Explicit declaration of a complex attribute
Abbreviated syntax must sound like jabberwocky at this point, but it's really a pretty neat concept. It uses a predefined format, such as CSV (comma-separated values), to essentially declare the arguments that will be passed to the appropriate class constructor beneath the covers. You can think of the String definition as the list of arguments you'd normally pass to a constructor, except that sometimes you don't need a comma to separate the arguments. Example 3-11 first creates an EllipseGeometry in C# and then assigns a Point to be its Center property by instantiating a new Point and passing the appropriate values to its constructor. The XAML code in the same example creates an EllipseGeometry and then assigns a Point to be its Center attribute using abbreviated syntax . The 0.5, 0.5 is parsed by the WPF engine, and the values are passed to a Point constructor as its arguments. Example 3-11. Abbreviated syntax and arguments in C#
A very common example of using abbreviated syntax to declare attribute values is the assignment of predefined color names to an attribute declared as type Brush, such as the Background attribute. Rather than forcing you to go through all the typing required to explicitly declare a Brush and set its color, XAML allows you to just declare the attribute as Red or Green instead. Figure 3-3 shows the result of declaring a Red SolidColorBrush as the background Brush for a Button using both abbreviated markup and by explicitly declaring the complex attribute. Example 3-12 shows the code used to declare both elements. Figure 3-3. Result of explicit declaration and abbreviated markup declaration of a Brush attribute on a Button Example 3-12. Explicit declaration of a Brush versus abbreviated markup
As you can see in Figure 3-3, both buttons are painted with the same background, regardless of the method used to declare the Brush. Abbreviated syntax is typically used because it requires less typing. There are no advantages to using explicit syntax in most cases where abbreviated syntax is available, and it's less typing for you. A more complex example is the common use of abbreviated markup syntax to declare elements of the type Point. Point is a common, complex attribute that is used in the declaration of almost every geometric XAML element. You can use the abbreviated markup syntax for a Point element wherever an element of type Point is declared. You'll notice in Example 3-13 that EllipseGeometry has several attributes. While RadiusX and RadiusY are Double values, the Center attribute for an EllipseGeometry is actually a complex attribute of type Point. In its abbreviated syntax, Point accepts two comma-separated values representing the X and Y positions, respectively. Example 3-13 shows different ways of using Point (in this case, it is used through the Center attribute). Example 3-13. Example of abbreviated markup versus explicit syntax
Elements that can be declared using abbreviated markup syntax are specifically noted in Part III. |
EAN: 2147483647
Pages: 217