WinFX application development raises abstraction to the level of a declarative programming model. To facilitate programming for this model a new XML-based declarative programming language, XAML, has been developed. Let's look at an XML example to see how little XML is necessary to create a user interface (UI) element. The following hypothetical example demonstrates that all you need to do to write a "Hello World" in XML (or really any markup language) is to initialize a few elements that have special meaning and represent user interface (UI) constructs to some hypothetical XML interpreter

<?xml version="1.0" standalone="yes"?>
<Window>
 <Button>Hello World</Button>
</Window>

XAML is based on expanding this basic principle to the point that entire multipaged applications can be produced principally with markup.

XAML is the prefered way to create a UI in the WinFX programming model because it provides a way to separate UI definition from logic, and enables you to integrate code by using code-behind files that are joined to the markup via partial class definitions, or for simple cases to also specify inline code using a XAML directive and CDATA. The ability to mix code with markup is important because XML by itself is so inherently declarative that it does not really suggest a model for flow control.

XAML enables you to create a UI entirely without using code. You can create quite elaborate documents or pages entirely in markup using controls, text, images, shapes and so forth. The following XAML example shows how little markup is necessary to create a button.

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

>
 <Button>Click Me</Button>
</Canvas>

However, if you want some event to occur when a user clicks the button, you will use code-behind written in a procedural language to handle the Click event that a button supports. The following example shows a XAML file, and a separate file that provides the code-behind for the XAML. When the button is clicked its background becomes red.

<Canvas 
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 x:Class="MyNamespace.MyCanvasCode">

 <Button Click="Button_Click">Click Me!</Button>
</Canvas>

namespace MyNamespace
{
 public partial class MyCanvasCode : Canvas
 {
 void Button_Click(object sender, RoutedEventArgs e)
 {
 Button b = e.Source as Button;
 b.Background = Brushes.Red;
 }
 }
}

This section explains the basic structure of XAML files—the steps you need to complete before you actually start adding UI elements. XAML files are conventionally XML files with an .xaml extension, and a namespace mapping to XML namespaces. Here, since we are documenting XAML for Windows Presentation Foundation (formerly code-named "Avalon"), all the namespace mappings are for the Windows Presentation Foundation and XAML namespaces. XAML has a set of rules to map classes into object tags, attributes into properties and events, and XML namespaces to CLR namespaces; for example, XAML element tags map directly to Microsoft .NET types as defined in the Windows Presentation Foundation assemblies. For more information, see XAML Namespaces and Namespace Mapping.

The Root Element

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



	...
	

</Canvas>

Adding Code

<Canvas
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 x:Class="MyNamespace.MyCanvasCodeInline"

>
 <Button Name="button1" Click="Clicked">Click Me!</Button>
 <x:Code><![CDATA[
 void Clicked(object sender, RoutedEventArgs e)
 {
 button1.Content = "Hello World";
 }
 ]]></x:Code>
</Canvas>

Underneath XAML is a collection of classes that correspond to objects / markup elements; however, some classes cannot be mapped to elements. Abstract classes, like ButtonBase, are used for inheritance and do not have corresponding XAML markup tags, and there are related nonabstract classes that are intended only as base classes because they don't have inherent rendering through content models and theme styles. Some classes lack default (parameterless) constructors, which is a XAML language requirement for being interpreted as an element when geneting objects based on the markup. Also, there are a number of classes that are valid as XAML elements but will only function properly when they are placed in an expected position of an overall content model or element tree. For instance, a MenuItem should typically only be placed as a child of a MenuBase descendant such as Menu.

FrameworkElement is the base UI class of the WinFX presentation framework. When designing UI, developers will use various shape, panel, decorator, or control classes, which all derive from FrameworkElement. A related base class, FrameworkContentElement, supports document-oriented elements that work well for a flow layout presentation.

Most interaction between an XAML application and an end user is accomplished through control classes. For example, the TextBox class enables users to enter text input and receive output. The following example shows the complete code needed to create a text box that allows you to enter and delete text. Notice that you simply use the <TextBox> object element syntax to create a text box object.

<TextBox>This is a Text Box</TextBox>

Note that this element has text content between the opening and closing tags, which would be analogous to InnerText in the XML document object model. The interpretation of such inner text varies somewhat from element to element depending on its content model, but for a typical control, this inner text becomes display text for that control in the UI.

XAML properties expressed as attributes enable you to add features to object element tags. For example, the following markup creates a button with red text and a blue background.

<Button Background="Blue" Foreground="Red">This is a button</Button> 

Properties as they appear as XAML attributes on an element are often inherited from base classes. For example, in the previous code example, the Background property is not an immediately declared property on the Button class, but is instead inherited from the base Control class. In order to be settable as a XAML attribute, a property must be public, must be read-write, and must reference a type that can be parsed/instantiated by a XAML reader application either on basis of a type-converted string representation or an object reference made through a markup extension.

Attribute and Property Element Syntax for Properties

Most properties can be set in a syntax that is analogous to XML attributes, as the previous example did.

Properties can also be defined using property element syntax. The syntax for such properties is <Object.Property>. For cases where both attribute and property element syntax are enabled, the two syntaxes are entirely equivalent, and in many such cases using the property element syntax will probably seem unnecessarily verbose. The following example shows exactly the same properties being set, this time using property element syntax.

<Button> <Button.Background> <SolidColorBrush Color="Blue"/> </Button.Background> <Button.Foreground> <SolidColorBrush Color="Red"/> </Button.Foreground> This is a button </Button>

There are a number of possible reasons for using the property element syntax. Some are required, some are optional. The following are some examples. Note that this is not a complete list; as you view the remainder of the documentation, it will be noted either in the references, conceptual material or examples whenever the property element syntax is a requirement. Property element syntax is typically not shown in cases where it would have been optional.

The Name Property

Many XAML elements support a Name property. This property is particularly important because it allows you to reference a particular element from code-behind, when that element was originally created from XAML markup. Even elements that cannot use Name because of their class inheritance can use an essentially equivalent x:Name Attribute for this same purpose.

Collections

The Resources collection is a collection property that is present on all framework-level elements, and setting this property in XAML requires the property element syntax. Without property element syntax, the parser wouldn't be able to apply multiple values using an attribute syntax, and couldn't just accept any child element of the element tag because the child element collection is what's used to compose a typical element tree of visible elements for an application, not the resources. Therefore, to specify resources for a given element, such as a Canvas, use the property element syntax <Canvas.Resources>, and then enclose all your resources for this collection within it as object element syntax. See Define and Reference a Resource for a more complete usage example.

By-Reference Types

Many properties where the underlying type of the property is a by-reference object type rather than a value type will necessarily require either a property element syntax to wrap an object element declaration (this is analogous to just-in-time constructor call to satisfy the reference), or a markup extension reference to an already existing instance (such as a resource). In some cases the by-reference types are conceptually akin to "alternate content" of a given element, and require declarative markup that must go beyond a simple attribute value. For example, here is the syntax required to define the ContextMenu of an arbitrary framework element (this is defined by a property that takes a ContextMenu object as its value):

<Button> <Button.ContextMenu> <ContextMenu> <MenuItem Header="1">First item</MenuItem> <MenuItem Header="2">Second item</MenuItem> </ContextMenu> </Button.ContextMenu> Right-click me!</Button>

In contrast, there are also a limited number of object types that support a "mini-language", which enables a new instance to be constructed and used as the property value on the basis of specially parsing the string value of a single attribute. The Thickness structure type, commonly used to denote measurements of a rectangular area such as a Margin, is an example of such a type with a mini-language exposed to promote ease of use in XAML markup.

Note:
On a technical level, such "mini-languages" are facilitated by supplying a particular type converter attribute and type-conversion implementation on a per-property basis rather than having type conversion be at the class level.

Other Required Property Element Usages

Many syntax constructs when writing a XAML style will require the property element syntax. For instance, the value of a property setter in a style, if it is anything other than a simple parsable value such as a double or a string, must be enclosed within a Setter.Value property element tag which is a property of the setter. For more information on style syntax, see Styles Overview.

Optional Usages

Optional usages include being specific about "spelling out" element content properties that the parser considers implicit. For instance, when declaring the contents of a Menu, you could choose to explicitly declare the Menu's Items collection as a <Menu.Items> property element tag, and place each MenuItem within it, rather than using the implicit parser assumption that all child elements of a Menu must necessarily be a MenuItem.

XAML creates UI elements such as buttons, text boxes, shapes, and so forth, but without code of some sort, XAML does not handle events. For example, if you have a button on a page, the XAML can create and display the button and its UI text and all manner of visuals and behavior, including some visual changes when the button is clicked, but beyond that the button will do nothing, yet. XAML and the larger Windows Presentation Foundation programming model enables you to associate events for elements and the handlers to be run in attribute syntax, with the name of the event being the attribute name, and the method name of the handler you will write as the (string) attribute value. You must then provide the implementation of that event handler in code-behind, in a language such as Microsoft Visual Basic .NET or C#. That event handler is expected to match the delegate for the appropriate event, and to be findable in the scope either of the page's partial class or by an otherwise qualified reference. The following example shows the XAML that creates the button, and the C# code-behind of a handler that does something meaningful to the button's characteristics by acting on data that was passed in the event's arguments. You've already seen this example in the context of describing the relationship of a XAML file and its code-behind.

<Canvas 
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 x:Class="MyNamespace.MyCanvasCode">
 <Button Click="Button_Click">Click Me!</Button>

</Canvas>

namespace MyNamespace
{
 public partial class MyCanvasCode : Canvas
 {
 void Button_Click(object sender, RoutedEventArgs e)
 {
 Button b = e.Source as Button;
 b.Background = Brushes.Red;
 }
 }
}

A particular event feature that is unique to Windows Presentation Foundation is the concept of a routed event. Routed events enable an event to be sourced by one element but then travel along a route that moves through the tree of elements that your application defines, and potentially to be handled by one or more elements along that route between the source element and the application's root. The most common scenario for routed events is handling input. For instance, in a small application, you could centralize all of your event handling logic in the root element, writing a single handler for each relevant event, identifying the source of the event with arguments, and reacting differently to each source with branching logic in the handler. You can also do the same thing when compositing controls and handling or exposing events from the control components more generally at the top level of the control.

Concepts

Other Resources