#1,214 – Naming Scheme for XAML Elements

Although XAML elements do not require a name, it’s sometimes useful to name them for debugging purposes–e.g. when using Visual Studio’s Live Visual Tree.

Below is a modest proposal for a naming convention for various WPF controls.

  • AccessText – at
  • Border – brd
  • BulletDecorator – bd
  • Button – btn
  • Calendar – cal
  • Canvas – cnv
  • CheckBox – chk
  • ComboBox – cbo
  • ContextMenu – ctx
  • DataGrid – dg
  • DatePicker – dat
  • DockPanel – dp
  • Expander – exp
  • Frame – fr
  • Grid – grd
  • GridSplitter – gsp
  • GroupBox – grp
  • Hyperlink – hyp
  • Image – img
  • InkCanvas – ikc
  • InkPresenter – ikp
  • Label – lbl
  • ListBox – lb
  • ListView – lv
  • MediaElement – me
  • Menu – mnu
  • NavigationWindow – nw
  • Page – pg
  • Panel – pnl
  • PasswordBox pwd
  • Popup – pop
  • ProgressBar – pb
  • RadioButton rdo
  • ResizeGrip – rgr
  • RepeatButton rpt
  • RichTextBox – rtb
  • ScrollBar – sb
  • ScrollViewer – sv
  • Separator – sep
  • Slider – sli
  • StackPanel – sp
  • StatusBar – stb
  • TabControl – tab
  • TabItem – tbi
  • TextBlock – tb
  • TextBox – txt
  • Thumb – th
  • ToolBar – tbr
  • ToolTip – tt
  • TreeView – tv
  • Viewbox – vb
  • VirtualizingStackPanel – vsp
  • Window – win
  • WrapPanel – wp

You could certainly go too far in naming controls in a WPF application. Instead of naming every single control, it’s probably more sensible to name a subset of controls, providing names when it makes sense.

#1,213 – Why You May Want to Name XAML Elements

In the days of Win Forms, we had to name every user interface element because the name is how we referenced the element when setting initial properties and then working with the element from code-behind.

In WPF, most developers have (hopefully) trained themselves to not bother with naming elements. Ideally, all interaction with a control is done through the use of commands and data binding, which means that there is then no need to ever access a control from code-behind.

Having said that, there is one valid use case for naming XAML elements in WPF. When you use a debugging tool that shows you the visual tree of an application, it’s helpful to have your elements named, so you can figure out what’s what.

Below is a XAML fragment for a simple WPF application. Note that I’ve named some of the elements (I’m not bothering to name simple labels).

    <Grid x:Name="grdMain" Margin="10">
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="Auto"/>
            <RowDefinition/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="Auto"/>
            <ColumnDefinition/>
        </Grid.ColumnDefinitions>

        <Button x:Name="btnPressMe" Grid.Row="0" Grid.Column="0" Margin="10" Command="local:SomeViewModel.PressMeCommand" Content="{Binding RelativeSource={RelativeSource Self}, Path=Command.Text}" Padding="10,5"/>
        <TextBlock x:Name="txbPressResults" Grid.Row="0" Grid.Column="1" Margin="10" Text="{Binding PressResults}"/>

        <TextBlock Grid.Row="1" Grid.Column="0" Text="Say something:"/>
        <TextBox x:Name="txtYourText" Grid.Row="1" Grid.Column="1" Text="{Binding YourText}"/>

        <TextBlock Grid.Row="2" Grid.ColumnSpan="2" Text="Gosh, I love this application"/>
    </Grid>

When I run the application, I can bring up Visual Studio’s Live Visual Tree and then explore the visual tree of the application. Notice the named elements in the visual tree, corresponding to the names given in the XAML.

Naming elements in this way can make debugging a bit easier when you’re navigating through the visual tree.

#157 – You Can Set Standard CLR Properties from XAML

If you create a custom class, you can instantiate instances of that class from XAML by adding the object to a resource dictionary.

    <Window.Resources>
        <m:Person x:Key="perBill" FirstName="William" LastName="Shakespeare" />
    </Window.Resources>

You might wonder whether your properties have to be WPF dependency properties in order to set their values from XAML.  It turns out that the properties on the custom class do not have to be dependency properties in order to be set from XAML.  They can be standard CLR properties.

    public class Person
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }

        public Person()
        {
        }
    }

#107 – Markup Extensions in the XAML Namespace

Some markup extensions are part of the extensions to XAML added for WPF (e.g. StaticResource).  But some markup extensions are part of the XAML vocabulary itself, typically prefixed with x:.  They are listed below:

  • x:Array – Allows including an array of objects in XAML
  • x:Null – A null value
  • x:Reference – A reference to another element defined in XAML  (XAML 2009)
  • x:Static – References a static element in code, e.g. value of a static property
  • x:Type – Specifies a .NET type

#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.

#103 – XAML 2009

.NET 4.0 introduced an update to the supported XAML vocabulary–the latest version supported is now XAML 2009.  WPF and Silverlight do not yet support XAML 2009 (.NET 4 / Visual Studio 2010), but still support XAML 2006.

With respect to Visual Studio 2010, therefore, the features introduced in XAML 2009 can only be used in loose XAML files.

XAML 2009 introduces the following new features, beyond what was present in XAML 2006:

  • x:Arguments allows calling non-default constructor (one with parameters)
  • x:FactoryMethod allows calling a static method to construct an object rather than using a constructor
  • x:Reference markup extension makes it easier to set a property value to point to an instance of another object
  • x:TypeArguments allows use of generics
  • Built-in support in x: namespace for standard CLR primitive data types (e.g. string, int, float, etc).  Avoids adding a separate XML namespace.

See also: XAML 2009 Language Features

#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