#106 – Set Property Value to Point to Another Object

There are times when you’d like to set a property value on one element to point to an instance of another element and do this in XAML, rather than in code.

An example of this is the CommandTarget property, which is used to indicate the control that should be the target of the command being initiated from a control.

For example, if you have a Button that executes a Paste command and you want the contents pasted in a TextBox, you’d set the button’s CommandTarget property to point to the TextBox.

This is done in XAML using the Binding markup extension, setting its ElementName property to point to the desired control.

 <Button Content="Paste" Command="ApplicationCommands.Paste"
     CommandTarget="{Binding ElementName=myTextBox}" />
 <TextBox Name="myTextBox"/>

XAML 2009 allows using the x:Reference markup extension, but this is not supported in compiled XAML in WPF.

 <Button Content="Paste" Command="ApplicationCommands.Paste"
     CommandTarget="{x:Reference myTextBox}" />
 <TextBox Name="myTextBox"/>

#105 – Viewing BAML as XAML

BAML is simply a compiled binary version of a XAML fragment.  The XAML elements are converted into equivalent binary objects.  This means that translating back from BAML to XAML is straightforward.

The simplest way to view a particular .baml file as XAML is to use the .NET Reflector tool.  After you download the tool, download the BamlViewer add-in for Reflector.  You’ll have to install the add-in (View | Add-Ins | Add).

Once installed, you just open the executable that contains the BAML, stored as a resource.  Then open the BAML Viewer from the Tools menu.

The BAML Viewer window will open and you can then navigate to the .baml that you want to examine (found embedded as a resource).  When you select the .baml file in the upper pane, the equivalent XAML will be displayed in the lower pane.

#104 – Using FindName to Find Named Children of a Control

When you create a XAML file for WPF in the normal Visual Studio environment, any control for which you provide a Name property will automatically get a backing variable defined that will let you reference the instance of that control directly from your code-behind.

But there are times when you don’t already have a reference variable pointing to a particular control, but only to the root element that exists at the top of the XAML file.  Instead of trying to navigate all the way down from the root element to the child that you’re looking for, you can use the FindName method.

In the example below, our root element is a Window and we want to get a reference to a child Label control that exists as a descendent of the window instance.

 Label myLabel = (Label)this.FindName("label1");

We pass in the name of the control, which we set in the XAML with the Name property.

#102 – Using XamlReader to Load a Loose XAML File

When you use Visual Studio to create the main Window, App and Page XAML files that make up a WPF application, code is automatically generated to cause the XAML (BAML) files to be read at runtime.

You can also use the XamlReader class to read loose XAML files–ones that have not be converted to BAML and stored as a resource in your application.

The static XamlReader.Load method will read a XAML file, instantiate all objects defined in the file, and return a reference to the top-level (root) element from the file.  (XamlReader is in the System.Windows.Markup namespace).

Assuming that you have a XAML filed named Stuff.xaml and it has a root element that is a StackPanel, you could load the file as follows:

 StackPanel sp1;
 using (FileStream fs = new FileStream("Stuff.xaml", FileMode.Open))
 {
     sp1 = (StackPanel)XamlReader.Load(fs);
 }

#101 – What Visual Studio Does with Your XAML

Given that XAML is just a declarative representation of the objects used by your WPF application, the objects need to be instantiated at runtime.

Here’s the process (e.g. for MainWindow.xaml):

  • While you work in designer, VS2010 automatically generates partial class (e.g. MainWindow.g.i.cs), including:
    • Reference variables for named elements in XAML  (e.g. myButton)
    • Code to instantiate XAML objects at runtime
  • When you build the project
    • All code (yours and VS2010-generated) is compiled
    • XAML is compiled into BAML (binary), stored in .baml file
    • All BAML files combined into single .g.resources file (e.g. MyApp.g.resources)
    • Executable is built, embedding the .g.resources file as a resource
  • At runtime
    • Window constructor calls InitializeComponent
    • InitializeComponent (in generated code) calls Application.LoadComponent, passing URI identifying XAML
    • LoadComponent loads binary XAML from embedded resource, creates all objects
    • As BAML is read, window’s IComponentConnector.Connect method is called, which hooks up local object references to the created objects and attaches event handlers

#100 – Loose XAML Files

A loose XAML file is a file containing XAML that has no associated code-behind and is not compiled into an application.  A loose XAML file can be loaded into Internet Explorer, where the user interface will be rendered.

Some rules about loose XAML files:

  • The top-level element cannot be a Window, but could be a Page or other GUI element (e.g. StackPanel).
  • The top-level element must have any required namespaces defined
  • The top-level element cannot have a x:Class attribute
  • No elements in the file can have event handlers
  • The only browser supported is Internet Explorer (Firefox can render loose XAML with WPF plug-in)

#99 – Creating Custom Objects in XAML

In XAML, you normally create elements that come from the standard WPF and XAML namespaces.  But you can also create objects that are instances of your own custom classes, or standard .NET classes in other namespaces.

You start by including a new namespace attribute, to indicate the namespace and assembly where your class can be found.  In the following example, we set up the m: prefix as pointing to the namespace MyStuff, which is in the assembly MyStuffLib.dll.

 xmlns:m="clr-namespace:MyStuff;assembly=MyStuffLib"

Now we can instantiate objects from the MyStuff namespace.  Assuming that MyStuff includes a Movie class, we could create an instance of a Movie in a window’s resource dictionary:

 <Window.Resources>
     <m:Movie x:Key="movie1" Title="Dances With Wolves" Director="Kevin Costner"/>
 </Window.Resources>

One reason for doing this would be so that we could then use data binding to bind one or more controls to the custom object.

#97 – Attached Properties

In XAML, attribute syntax is normally used to set the value of a property on an object.  But through the use of attached properties, you can set a value for a property that comes from another object.

Attached property syntax follows the form TypeName.PropertyName, where the type named is the type where the property is defined.

In the example below, we have two Button controls contained in a grid.  To indicate their position in the grid, we specify Grid.Row and Grid.Column properties for each.  The buttons don’t have Row and Column properties and neither does the Grid .  But the Grid does have Row and Column as attached properties–meaning that it can apply the properties to other objects, indicating where those objects should appear in the grid.

 <Grid>
     <Button Grid.Row="1" Grid.Column="0" Content="Dee" Height="23" Name="button1" Width="75" />
     <Button Grid.Row="1" Grid.Column="1" Content="Dum" Height="23" Name="button2" Width="75" />
 </Grid>

#95 – x:Name vs. Name

You’ll typically see a Name property on XAML elements.  This property can be used in your code-behind, as a reference to the object being created.

 <Button Content="Button" Height="23" Name="button1" Width="75" Click="button1_Click" />
 <Button Content="Button" Height="23" Name="button2" Width="75" />

But you might also see x:Name being used (attribute syntax) in XAML.

 <Viewport3D Name="viewport1">
     <ModelVisual3D x:Name="visual1">
     </ModelVisual3D>
 </Viewport3D>

The Name property can be used with elements that inherit a Name property from their base class (e.g. FrameworkElement).  But for classes that don’t define a Name property or inherit from a class that does, you must use the x:Name property if you want to reference the object from your code-behind.

In general, Name and x:Name are interchangeable.  The former is an actual property on the class and the latter is a directive that comes from the default x: namespace and is used by the XAML parser.

#94 – Naming Elements

If you use drag and drop in Visual Studio 2010 to create new elements and include them in the underlying XAML file, each element is automatically given a name:

 <Button Content="Button" Height="23" Name="button1" Width="75" />
 <Button Content="Button" Height="23" Name="button2" Width="75" />

But setting this Name property is optional.  If you remove the Name properties, the elements will still get created and displayed properly.

Naming elements in XAML is required when you want to reference those elements in your code-behind.  For example, with the named buttons above, we can then write the following C# code:

 button1.Content = "Button 1";
 button2.Content = "This is button 2";

The name is used in code as a reference to the corresponding object created by the XAML parser.