Storyboards can only be defined on root elements or as part of a style, even though every framework element has a Storyboard collection. The difference between setting the Storyboard attribute of the root element and setting the Storyboard attribute of a style can be summed up as follows:

A style-based Storyboard can be applied to any element, not just the root element.

The target of each SetterTimeline is assumed to be the element for which the style is defined, so you do not specify the SetterTimeline object’s TargetName.
Read the rest of this entry »

A Style is a set of properties applied to an element that can be used to describe the appearance of an element. It is used in a similar manner as styles declared in CSS. A style can be applied locally to a single element, or it can be declared globally and referenced from the element. Styles can also be declared such that they affect all instances of a given type, such as Button.

A XAML Style is a collection of one or more Setter elements that act upon a specified dependency property, such as Background or Foreground. Remember that a Key value is required if the style will be applied by reference to an element.
Read the rest of this entry »

When adding resources, you must add the appropriate namespace to the root element. You’ll also need to give it a name to differentiate it from the default namespace. The default namespace, which references Avalon, contains the definitions of Avalon elements, such as Button, Page, and StackPanel. The namespace that must be added to define resources is the XAML namespace and describes the language itself.

Because resource definitions require the use of XAML-specific tagswhich are not described by the default namespaceyou must declare a reference to the XAML namespace and use it to prefix those attributes found only there, such as Key.
Read the rest of this entry »

The concept of codebehind has been mentioned but not fully explored yet. You’ve already noted that event handlers can be assigned to elements and implemented in code and that the attribute name must exactly match the handler name in code. The event handlers specified by name as attributes for controls are associated with the codebehind in a C# or VB.NET file during the compilation process. The compiler generates a partial class for XAML and then assembles it with the code, which defines the rest of the class in a codebehind file. This allows the two pieces to be tied together when the code is interpreted within the runtime engine.

But there are other things that can be accomplished in code besides handling events. Many applications require initialization of data sources, or automatically adding fields to the user interface depending on the user’s role. These things cannot be done in XAML; they must be done programmatically.
Read the rest of this entry »

All XAML elements are an XML representation of CLR classes, but not all CLR classes are represented in XAML. Most of those represented are user-interface elements and are ultimately derived from System.Windows.UIElement, which provides basic visual user-interface properties that are shared by most XAML elements . A System.Windows.UIElement can render itself, receive input via the keyboard and mouse, visually size and position its child elements, and raise events.

Not all XAML elements are derived from System.Windows.UIElement. Some, such as LineBreak, TableColumn, and Document, are derived from System.Windows.Frame-workContentElement. System.Windows.FrameworkContentElement elements cannot render themselves but are instead rendered by another class, usually the container in which they have been placed.
Read the rest of this entry »