The Binding Markup Extension

Last week I wrote a post about Markup Extensions with the intention of providing some background information for the Binding Class. If you’re doing an WPF or Silverlight development the Binding class is very important to know about. Further more, as a developer working side by side with a designer most of the work of integrating the design and the code is done through data binding.

The Basics

The Binding class is a very common type of markup extension. Its purpose is to update elements in your UI with values defined at other locations. Most of the time these other data sources will be ViewModels you create but it is also possible to bind to other UI elements.

So, for example, suppose you have a Customer object with a Name property and you want to display that in a text box. The Xaml to do this would look like this:

<TextBox Text="{Binding Name}" />

Pretty simple. The Binding markup extension accepts a Path as its default parameter. If you wanted you could optionally specify the full parameter name as well.

<TextBox Text="{Binding Path=Name}" />

These two snippets are effectively the same.

The Binding extension uses reflection based on the string you specify for the path to drill down into your object. So optionally you could choose to display the length instead of the actual string of the name, for example.

<TextBox Text="{Binding Path=Name.Length}" />

Additionally you can access indexed values through the path with this syntax:

<TextBox Text="{Binding Path=Name[0]}" />

Which would give you the first character of the string instead of the full name. These last two snippets are actually more tricky than this though. Since a string is immutable the character indexer and Length properties are read-only and Binding expressions do not like to bind against read-only properties. In this case we would need to either switch our Mode to be OneWay or OneTime.

Modes

<TextBox Text="{Binding Path=Name[0], Mode=OneTime}" />

This will result in a TextBox loaded with the string representation of the length of the name it is bound to but editing the text box will not actually do anything other than change the text in the text box. There are 5 modes to be aware of.

  • TwoWay
  • OneWay
  • OneTime
  • OneWayToSource
  • Default

Most of these are pretty straight forward but, surprisingly, Default can actually be tricky. Different controls may have different modes as default so if your binding doesn’t seem to be setting a value in the direction you’re expecting try a different mode.

UpdateSourceTrigger

This is the name of another important property. It is an enum value indicating when your binding should update the source (your ViewMode, a Customer in this case). So if we are bound to the Name property of Customer then whenever we type in the TextBox, by default, the name will only be updated when the TextBox loses focus. That is because for the Text property of a TextBox the UpdateSourceTrigger is set to LostFocus. If we want real time updating we could writing our binding like this:

<TextBlock Text="{Binding Name}" />
<TextBox Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />

Now as we type in the TextBox the TextBlock will be immediately updated. There are 4 possible values for UpdateSourceTrigger.

  • Default
  • PropertyChanged
  • LostFocus
  • Explicit

The default behaves similarly to the Mode in that different properties for different controls might have a different value for default. You should note that these usually only matter for OneWay or TwoWay bindings and its also dependent upon your ViewModel being implemented correctly (i.e. it implements the INotifyPropertyChanged interface). I’ll discuss view models more in another post however.

Source

Another important property is the Source property. In this example so far I haven’t specified the Source therefore I have been using the default source. By default the source is the value of the controls DataContext property. So that means to get the snippets above to work I had to set the DataContext property to a Customer object. It is also useful to know that if a Controls DataContext is null then it will use its parents DataContext and so on. So for my example I set the root windows DataContext to a customer object which allowed me to use the above Binding syntax.

public MainWindow()
{
    this.InitializeComponent();
    this.DataContext = new Customer { Name = "Justin Chase" };
}

This is a very simplistic way to do this but it works. Additionally you could specify your Source using the Source property. Typically you would do this by pointing it to a resource defined in your resources.

<Window.Resources>
        <local:Customer x:Key="customer" Name="Justin Chase" />
    </Window.Resources>
    
    <Border HorizontalAlignment="Center" VerticalAlignment="Center">
        <StackPanel>
            <TextBlock 
                Text="{Binding Name, 
                Source={StaticResource customer}}" />
            <TextBox 
                Text="{Binding Name, 
                UpdateSourceTrigger=PropertyChanged, 
                Source={StaticResource customer}}" />
        </StackPanel>
    </Border>

This is effectively the same except I now have no code-behind. As a more robust solution to this problem in WPF you can use the ObjectDataSource which gives you capabilities to construct objects in Xaml with constructor parameters or through factory methods. There are still quirks but it’s worth looking into.

Alternately I could have set a parent controls DataContext with a Binding instead of setting the Source on every child Binding like this.

<Window.Resources>
    <local:Customer x:Key="customer" Name="Justin Chase" />
</Window.Resources>

<Border HorizontalAlignment="Center" VerticalAlignment="Center">
    <StackPanel DataContext="{Binding Source={StaticResource customer}}">
        <TextBlock 
            Text="{Binding Name}" />
        <TextBox 
            Text="{Binding Name, 
            UpdateSourceTrigger=PropertyChanged}" />
    </StackPanel>
</Border>

It’s especially important to understand the Source property when you find yourself creating DataTemplates, because typically your DataContext is set from an unknown source and you will not be able to set the Source.

Converter and ConverterParameter

The Converter is a wonderful thing and is very simply to understand. The key to a good converter is the IValueConverter interface. Simply implement this and add your class to your Resources and you’re ready to convert! The converter simply converts a value to and fro as it passes through the Binding. I will write more details on this in another post.

The framework comes with a number of Converters but the only one I’ve ever found to be of any use is the System.Windows.Controls.BooleanToVisibilityConverter. But you will no doubt find the need to create many for yourself.

One cautionary note with converters, Converters are powerful but they can also be used to mask architectural problems with ViewModels. If you find yourself using a Converter for anything more than just changing something into a string and back you should probably take a step back and rethink things. I’m not saying you definitely have a problem but it’s worth thinking twice about. I will write in more detail about how to properly construct ViewModels in another post.

ElementName and RelativeSource

The element name is an alternative to the Source property. You either specify the ElementName or the Source but not both. If you specify the ElementName then you’re saying that you want to bind against the value of another control in your UI. The Path is essentially the same except you’re binding against a Control instead of a ViewModel. If you have a control that has a name specified with the x:Name attached property then that is the value you will want to put into the ElementName property.

<TextBlock 
    Text="{Binding Text,
    ElementName=tb}" />
<TextBox 
    x:Name="tb"
    Text="{Binding Name, 
    UpdateSourceTrigger=PropertyChanged}" />

Additionally you can set the RelativeSource property if you need to get to controls in a totally different branch of the control hierarchy or different properties of yourself. The value passed into the RelativeSource property is an Markup Extension, aptly named, RelativeSource. To acheive the same thing as above except using the RelativeSource property you could do this:

<StackPanel DataContext="{Binding Source={StaticResource customer}}">
    <TextBlock 
        Text="{Binding Children[1].Text,
        RelativeSource={RelativeSource 
            Mode=FindAncestor, 
            AncestorType={x:Type StackPanel}}}" />
    <TextBox
        Text="{Binding Name, 
        UpdateSourceTrigger=PropertyChanged}" />
</StackPanel>

ValidationRules

I was struggling with what to write about in this section. I’ve decided to just be honest. My work with CSLA has caused me to come to the conclusion that the validation rules mechanism in WPF / Silverlight Binding expressions is simply inadequate. So basically what I’m saying to you is to simply not use it at all, it’s awful.

The main reason why I think you shouldn’t use it is because it’s completely predicated on the mechanism of throwing exceptions from within a property. Which is a pretty rude thing to due normally. Additionally it requires that you throw a specific WPF type of exception to trigger the validation failure rule… which tightly binds you to WPF. This is evil. And frankly, it’s easy to just write your own validation scheme that WPF / Silverlight is perfectly happy with. In CSLA we wrote a validation scheme that includes prioritization, dependency, asynchrony, severity and multiplicity. And it wasn’t even that hard…

So do yourself a favor and don’t even bother with the built-in validation mechanisms. Additionally, if I didn’t quite sell you with the rational approach, then be aware that the XAML required to write WPF style validation is so Flying Spaghetti Monster-awful that it makes me want to barf just looking at it.

StringFormat

This is a pretty cool little property that is relatively new to WPF that allows you to format the output of the bound text without having to actually write a custom converter. Essentially the string that goes into this property is the same string that you would put into a call to string.Format(…). The only difference is that if you want to put {0} at the beginning of the string you have to escape it with an extra {}… yeah I know. Its hideous but better than not having it… barely. Here is an example of the two usages:

<TextBlock 
    Text="{Binding Name.Length,
    StringFormat='Name Length: {0}'}" />
<TextBlock 
    Text="{Binding Name.Length, 
    StringFormat='{}{0:C}'}" />

IsAsync

Frankly… stay away from this one too. I’ve wanted to use this so many times but have always found the model to be overly simplistic. Asynchronous code is hard, there is no free pass and this just adds to the confusion. You might give it a try if you have some ultra simple scenario but don’t expect it to take you into a completely asynchronous UI.

Many others…

For a complete list of properties head to this site on MSDN http://msdn.microsoft.com/en-us/library/system.windows.data.binding_properties.aspx

Author: justinmchase

I'm a Software Developer from Minnesota.

%d bloggers like this: