A trigger waits for something to happen (usually by listening for a control event to be raised), and when that event is raised, it invokes one or more actions (which do something in response). Unlike WPF, Silverlight doesn't (for the most part) have a concept of triggers and actions. The EventTrigger is the only trigger available, and it will only respond to the Loaded event of a control and start an animation, meaning that it has limited use (and any use of it is generally discouraged). Because of this lack of triggers and actions in Silverlight (and due to the inability to extend WPF's triggers and actions), the Expression Blend team created its own triggers and actions implementation (in addition to another concept called behaviors, discussed shortly).

Although designed for use with Expression Blend, you can also use any of the predefined triggers, actions, and behaviors based on this implementation in Visual Studio (although there will be no designer support like there is in Expression Blend). In addition, you can write your own triggers, actions, and behaviors.

Configuring Triggers and Actions using Expression Blend

The easiest way to configure triggers and actions by far is via Expression Blend. Triggers and actions (and behaviors) were specifically designed for use by designers so that they didn't need to write and edit code, and thus Expression Blend has extensive support for them. In Expression Blend, you can simply drag an action from the asset library (you'll find them in the Behaviors category, as shown in Figure 10-1) and drop it on a control.

Figure 10.1. Behavior assets in Expression Blend

Blend will automatically create a trigger and assign the action to it. You can then configure the trigger and action via the Properties window. Visual Studio unfortunately doesn't have this level of support built in; instead, you must manually define the trigger and action in XAML by hand (although you can configure the trigger and the action once you've created them via the Properties window).

If you plan to leverage triggers and actions extensively in your application, using the Expression Blend designer (instead of Visual Studio's) will make the whole process much easier and faster.

Note

Coverage of Expression Blend is beyond the scope of this book. However, Kirupa Chinnathambi has a great blog post on using behaviors in Expression Blend at http://blog.kirupa.com/?p=351. You assign triggers and actions to controls in Expression Blend in much the same way as he demonstrates with behaviors. In addition, an article on the SilverlightShow.net web site by Andrej Tozon also walks you through using behaviors with Expression Blend; see www.silverlightshow.net/items/Exploring-Silverlight-behaviors-look-Ma-no-code.aspx.

xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
xmlns:ei="http://schemas.microsoft.com/expression/2010/interactions"

<Button Content="Save" Height="23" Width="75">
    <i:Interaction.Triggers>
        <i:EventTrigger EventName="Click">
            <!--Assign action(s) here-->
        </i:EventTrigger>
    </i:Interaction.Triggers>
</Button>

<ei:CallMethodAction TargetObject="{Binding ElementName=productsDDS}"
                     MethodName="SubmitChanges"/>

Let's start by creating a custom trigger. When writing custom triggers (and this applies to actions and behaviors too), you are encapsulating a piece of logic in a reusable interaction component that you can attach to a control. Although you are writing these components in code, (in essence) you are writing this code in a reusable componentized fashion to save you from writing code when it comes to actually applying the logic to elements in your user interface (where you can then apply and configure this logic declaratively in XAML).

Let's create a trigger that will invoke the associated action(s) when the Click event is raised on the Button control it is attached to. Add a new class to your project called ButtonClickTrigger. This class should inherit from either TriggerBase or TriggerBase<T> (from the System.Windows.Interactivity namespace). By having it inherit from TriggerBase<T>, you are able to constrain the trigger to only applying to a given control type. For this example, it will inherit from TriggerBase<Button>.

The next step is to override the OnAttached and OnDetaching methods and handle any events on the attached control that will be used to trigger the corresponding action(s) (including removing those event handlers when detaching). In our trigger, we want to handle the Click event of the button, so we handle that event on the control exposed by the AssociatedObject property on the base class.

The final step is to invoke the actions that have been associated with the trigger, by calling the InvokeActions method on the base class. This takes a parameter that allows an object to be passed to the actions, but we can assign it to null because we have nothing to pass.

The code for the trigger follows; as you can see, it is very simple:

public class ButtonClickTrigger : TriggerBase<Button>
{
    protected override void OnAttached()
    {
        base.OnAttached();

        AssociatedObject.Click += new RoutedEventHandler(AssociatedObject_Click);
    }

    protected override void OnDetaching()
    {
        base.OnDetaching();

        AssociatedObject.Click -= new RoutedEventHandler(AssociatedObject_Click);
    }

    private void AssociatedObject_Click(object sender, RoutedEventArgs e)
    {
        InvokeActions(null);
    }
}

You can now use this in place of the more generic EventTrigger trigger, without the need for configuring the event name. Note that, of course, you will have to assign a namespace prefix to its namespace in your XAML file in order to be able to use it:

xmlns:b="clr-namespace:AdventureWorksLOB.Behaviors"
<Button Content="Save" Height="23" Width="75">
    <i:Interaction.Triggers>
        <b:ButtonClickTrigger>
            <!--Assign action(s) here-->
        </b:ButtonClickTrigger >
    </i:Interaction.Triggers>
</Button>

Let's create a custom action that will be performed in response to a trigger. This action will call the SubmitChanges event on the target DomainDataSource control. Add a new class to your project called SubmitChangesAction. This class should inherit from TriggerAction, TargetedTriggerAction, or their generic counter parts (from the System.Windows.Interactivity namespace).

For this example, the control we are attaching the action to is a button, but we actually need to act on a DomainDataSource control. Therefore, we'll inherit from TargetedTriggerAction<DomainDataSource>.

The next step is to override the Invoke method. You can now implement your action's logic in this method. Note that this method has a single parameter, which will pass into the method whatever object was passed to the parameter of the trigger's InvokeActions method. The following code is for an action that calls the SubmitChanges method on the target control when it is invoked:

public class SubmitChangesAction : TargetedTriggerAction<DomainDataSource>
{
    protected override void Invoke(object parameter)
    {
        Target.SubmitChanges();
    }
}

Assigning it as an action to be invoked by our ButtonClickTrigger trigger, our final trigger/action declaration to implement the scenario in XAML is

<Button Content="Save" Width="75">
   <i:Interaction.Triggers>
      <b:ButtonClickTrigger>
         <b:SubmitChangesAction TargetObject="{Binding ElementName=productsDDS}" />
      </b:ButtonClickTrigger>
   </i:Interaction.Triggers>
</Button>

To make this trigger/action pair even easier to use in Expression Blend, you can specify a default trigger that the action will be assigned to when it is dropped onto a control. Our SubmitChangesAction action has been designed for use in conjunction with a ButtonClickTrigger trigger, so ideally, when the action is dropped onto a control, a ButtonClickTrigger trigger should be created automatically for the SubmitChangesAction action to be assigned to. We can tell Expression Blend which trigger the action should use by default by decorating the action class with the DefaultTrigger attribute, like so:

[DefaultTrigger(typeof(Button), typeof(ButtonClickTrigger))]

The first parameter specifies the type of control that the action is attached to, and the second parameter specifies the type of trigger to use when attached to a control of that type. For example, in the preceding example, we are specifying that when the action is attached to a Button control, it should use the ButtonClickTrigger trigger by default. You can apply this attribute multiple times to the class if you wish, enabling you to specify a different default trigger for each type of control the action is attached to. You can also pass additional values to be assigned to the trigger by passing additional parameters to the DefaultTrigger attribute.

This is a very simple action that we've created, but you can create much more complex actions depending on the needs of your user interface. However, they are discrete atomic blocks of interaction logic only; they do something and then exit (you can think of them as being much like a method in code). Actions cannot wait for another event to be raised, nor can they preserve their state between trigger invocations. If you need to provide a more persistent interaction, implementing behaviors may be a more suitable alternative.

Triggers and actions often come under the banner of behaviors, so when you read about behaviors, often you will find that the author is actually referring to triggers and actions rather than behaviors (which can make the concept somewhat confusing). Even Expression Blend includes actions in the Behaviors category in the Asset Library.

A behavior is actually a different concept than triggers and actions (although they do share some similarities). Whereas triggers and actions are defined separately (and can be mixed and matched), behaviors combine these two concepts into a single component, tightly coupling the trigger and the action. Behaviors are attached and detached from a control in the same way as triggers are (and thus are alive for the lifetime of the control they are attached to). However, unlike a trigger, which expects to have one or more associated actions to perform the interaction logic, the behavior handles all the interaction logic internally.

At a conceptual level, you can think of a behavior as being designed to add additional functionality to the control that it is attached to. This may be a simple trigger/action combination or may implement a more involved interaction such as a drag-and-drop type operation.

Behaviors inherit from either the Behavior class or the generic Behavior<T> class and are found in the System.Windows.Interactivity namespace.

One of the big advantages of combining triggers and actions into a single component is that it enables a preservation of state between the "trigger" events. A typical scenario where you might want to maintain state between events is implementing a drag-and-drop operation. To implement this type of operation, you need to handle multiple events (including the MouseDown, MouseMove, and MouseUp events), and maintain the state of the drag-and-drop operation between them.

Behaviors typically define additional behavior and logic for the control that they are attached to as opposed to interacting with other controls (unlike the custom action we created that interacts with a DomainDataSource control when a button is clicked).

For example, a typical behavior to add to a text box might be one that automatically selects all the text when the text box gets the focus. This behavior entirely revolves around the text box it is attached to only, without interacting with any other controls.

However, there's nothing stopping you from adding the ability to interact with other controls in a behavior; there's simply no built-in provision for it (i.e., there's no TargetedBehavior base class provided like there is a TargetedTriggerAction base class).

Let's revisit our previous example of calling the SubmitChanges method on a DomainDataSource control when a button is clicked, but this time, we will implement it as a behavior:

public class SubmitChangesBehavior : Behavior<Button>
{

[CustomPropertyValueEditor(CustomPropertyValueEditor.ElementBinding)]
    public DomainDataSource Target
    {
        get { return (DomainDataSource)GetValue(TargetProperty); }
        set { SetValue(TargetProperty, value); }
    }

    public static readonly DependencyProperty TargetProperty =
        DependencyProperty.Register("Target", typeof(DomainDataSource),
                                    typeof(SubmitChangesBehavior), null);

    protected override void OnAttached()
    {
        base.OnAttached();

        AssociatedObject.Click += new RoutedEventHandler(AssociatedObject_Click);
    }

    protected override void OnDetaching()
    {
        base.OnDetaching();

        AssociatedObject.Click -= new RoutedEventHandler(AssociatedObject_Click);
    }

    private void AssociatedObject_Click(object sender, RoutedEventArgs e)
    {
        Target.SubmitChanges();
    }
}

You can now implement this behavior in XAML like so:

<Button Content="Save" Width="75">
   <i:Interaction.Behaviors>
      <b:SubmitChangesBehavior Target="{Binding ElementName=productsDDS}" />
   </i:Interaction.Behaviors>
</Button>

The big question you probably want an answer to is when should you use a behavior over a trigger/action combination? Ultimately, there are no fixed rules, and in some cases, there is a bit of overlap where either means is appropriate (as was demonstrated with our button click/submit changes example).

If the trigger and action are intrinsically tied together and you want to minimize the amount of configuration necessary when using them, then a behavior is probably the ideal candidate to implement the interaction logic. If you have complex interaction logic where state needs to be preserved between event handlers (such as a drag and drop operation), then a behavior is essentially your only choice.

However, if you want to provide a more flexible use story and have interaction logic that could be triggered by different types of controls (and/or in different types of ways), then implementing a separate trigger and action may be a better plan of action.

The possibilities are endless with triggers, actions, and behaviors, and going back through the examples provided throughout this book until now, you could replace almost all of the code-behind that we used with a trigger/action combination or a behavior. Now that you understand these concepts, every time you consider adding code to the code-behind, first consider whether encapsulating the logic in a trigger/action pair or a behavior might be a better alternative.

Triggers, actions, and behaviors are a very powerful tool at your disposal, promoting both code reuse and interaction logic modularization/encapsulation. They are testable, and (arguably) the biggest advantage is that they reduce/remove the need for designers to write interaction logic code.

As you may recall from Chapter 3, "An Introduction to XAML," the design time data mechanisms can be found in the Expression Blend 2008 namespace (http://schemas.microsoft.com/expression/blend/2008), which is automatically declared in your XAML files with a prefix of d. In this namespace, you will find the following data-related attached properties:

You will also find the DesignData and DesignInstance markup extensions. We'll be using these to provide the blendability features in the XAML designer.

Let's start by defining the type of data that we will bind to, so that the data binding expression builder (discussed later in this chapter) knows the structure of the data that we are binding to. Back in Chapter 6, "Implementing Summary Lists," you may have noticed that when you drag an entity (returned from the server via RIA Services) from the Data Sources window and drop it onto the design surface, the DomainDataSource control that's created for you has a design time data property already applied:

<riaControls:DomainDataSource AutoLoad="True"
                      d:DesignData="{d:DesignInstance my1:ProductSummary,
                                    CreateList=true}"
                      Height="0" Width="0"
                      LoadedData="productSummaryDDS_LoadedData"
                      Name="productSummaryDDS"
                      QueryName="GetProductSummaryListQuery">
    <riaControls:DomainDataSource.DomainContext>
        <my:ProductsContext />
    </riaControls:DomainDataSource.DomainContext>
</riaControls:DomainDataSource>

The rather confusingly named d:DesignData design time attached property (it has nothing to do with the d:DesignData markup extension, discussed shortly) is used to define the type of data that is served by a data source control (via its Data property). Hence, this property can only be applied to data sources (such as the DomainDataSource control). The benefit of applying this design-time property to the DomainDataSource control is that you will now be able to select the properties to bind to in the data binding expression builder (on the specified entity) when binding to data that it returns (as you'll see in Figure 10-5 later in this chapter).

To configure this property, we assign it a d:DesignInstance markup extension. This markup extension is primarily used to return an object of a given type (or a collection of objects of that type). The default property on this markup extension is the Type property. You'll note from our example that it specifies that the DomainDataSource control will be returning ProductSummary entities. You will also note that the CreateList property of this markup extension is set to true. This is used to indicate whether the d:DesignInstance markup extension should return a collection of the given object type or a single instance of the object type.

By default, the d:DesignInstance markup extension reflects over the given object type and creates and returns a corresponding substitute design time type (or an empty collection of that type if the CreateList property is set to true), which the XAML designer can use where required. However, it also has an IsDesignTimeCreatable property, which, when set to true, will actually instantiate and return an object of the given type (which is only of use when the CreateList property is set to false). Once you assign values to that object's properties in its constructor, these values will appear in the XAML designer—essentially populating it with data at design time.

You can also assign the d:DesignInstance markup extension to the d:DataContext design time attached property. Whereas the d:DesignData property could only be applied to data source controls (which serve up data), the d:DataContext property is designed to be applied to controls that will bind to data via their DataContext property. Like data assigned to the DataContext property of a control, the value assigned to the d:DesignContext property will be inherited down the object hierarchy. For example, setting the d:DataContext property on a Grid (as demonstrated by the TextBlock control in the following example) will enable the data binding expression builder to display the available properties that the controls within the Grid can be bound to.

<Grid d:DataContext="{d:DesignInstance Type=my1:ProductSummary}">
    <TextBlock Text="{Binding Path=Name}" />
</Grid>

We've made the designer much friendlier for creating bindings, so let's now look at populating it with some sample data at design time. Although we can populate a single instance of an object with data in its constructor and set the IsDesignTimeCreatable property on the d:DesignInstance markup extension to true to populate the XAML designer with some data (as was previously demonstrated), it is hardly an ideal means for doing so. The design-time data has to be hard-coded in the class (not a good idea), and this method is only suitable when binding to a single object (rather than a collection of objects). There is another option however, and that's using the d:DesignData markup extension (in place of the d:DesignInstance markup extension).

The d:DesignData markup extension has only a single property, named Source (which is, therefore, its default property). The design-time data needs to be defined in a separate XAML file, and you simply point the Source property to a XAML file that defines the design-time data, and that data will then be displayed in the XAML designer. The easiest way to create this XAML file and populate it with data is from within Expression Blend; there, you can import some sample data from XML, create random data conforming to the structure of a given class, or simply create your own structure before populating it with random data as required. Explaining how to create sample data files is beyond the scope of this book, but you can find more information on doing so in Expression Blend in the Expression Blend help or manually in Visual Studio at this MSDN page: http://msdn.microsoft.com/en-us/library/ff602279(VS.95).aspx. The sample data XAML files should have a Build Action of either DesignData (where a substitute design-time type will be generated and used in place of the objects that the sample data is populating), or DesignDataWithDesignTimeCreatableTypes (where the actual objects the sample data is populating are instantiated and used at design time). You can then use the d:DesignData markup extension to point to the sample data XAML file and assign it to the d:DataContext attached property as required:

d:DataContext="{d:DesignData Source=/SampleData/ProductSampleData.xaml}"

If you set the Source property of the binding, it will use the given object as the binding source instead of the object assigned to the DataContext property of the control. If you're assigning this property in XAML, you will most likely be binding it to a resource (using the StaticResource markup extension).

For example, let's say you have a Product object that is defined as a resource (with productResource as its key) somewhere up the object hierarchy (defining and instantiating a class as a resource for binding to will be discussed later in this chapter). The standard way of binding to this resource is by assigning it to the DataContext property of the target control using the StaticResource markup extension. For example, binding the Name property of the Product object to the Text property of a TextBox control, you would use the following XAML:

<TextBox DataContext="{StaticResource productResource}" Text="{Binding Name}" />

Using the Source property, the following binding expression will provide the same results as the previous one:

<TextBox Text="{Binding Name, Source={StaticResource productResource}}" />

The Source property provides you with an advantage in the situation where you want to bind a control's property to a given source, without altering the inherited data context for its child controls (where that data context has been set somewhere further up the hierarchy) or altering the binding source for its other properties.

In Chapters 6 and 7, we were binding the ItemsSource property of various controls to the Data property of a DomainDataSource control but didn't go into depth on how this was achieved. The DomainDataSource control was retrieving data from the server and exposing that data publicly via its Data property. We then consumed that data by binding the ItemsSource property of our ListBox/DataGrid/DataForm control to the DomainDataSource control's Data property. To bind a control's property to the property of another (named) control in the view like this, we needed to use a special kind of binding called ElementName binding. Using the ElementName property on a binding, you could provide it the name of a control (within the same name scope) that would act as the source for the binding (instead of the object assigned to the control's DataContext property). Let's take a look at some examples of employing ElementName binding to bind the properties of two controls together in XAML.

A very simple example is to link the Text property of two TextBox controls. When you modify the text in one text box, the second text box's text will update automatically:

<StackPanel>
    <TextBox Name="FirstTextBox" />
    <TextBox Name="SecondTextBox" Text="{Binding Text, ElementName=FirstTextBox}" />
</StackPanel>

Similarly, we can display the current value of a Slider control in a text block by binding the Slider control's Value property to the TextBlock control's Text property:

<TextBlock Text="{Binding ElementName=sourceSlider, Path=Value}" />

The following XAML demonstrates taking the ItemsSource property of a ListBox control (acting as the target), and binding it to the Data property of a DomainDataSource control:

<ListBox ItemsSource="{Binding ElementName=productSummaryDDS, Path=Data}" />

This example demonstrates binding the IsBusy property of the BusyIndicator control to the IsBusy property of a DomainDataSource control (which will display the BusyIndicator control when the IsBusy property of the DomainDataSource control is true):

<controlsToolkit:BusyIndicator
    IsBusy="{Binding ElementName=productSummaryDDS, Path=IsBusy}" />

In this final example, we are binding the Target property of the Label control to a text box. Note that by not specifying a path for the binding, we are binding the Target property to the text box itself, not a property on that text box:

<sdk:Label Content="Name:" Target="{Binding ElementName=ProductNameTextBox}" />

You may have noticed that there is a RelativeSource property on the Binding markup extension. This enables you to bind to a source relative to the target. To obtain a reference to the source to assign to this property, you need to use the RelativeSource markup extension RelativeSource markup extension. Somewhat limited in comparison to the corresponding markup extension in WPF (which can search for an ancestor of a particular type), the RelativeSource markup extension only supports two modes: Self and TemplatedParent.

The Self mode returns the target control and is useful for binding together two properties on the same control. This is generally most useful when you have attached properties on a control that you want to bind to properties on the control itself. For example, perhaps you want to display a tooltip when the user hovers over a text box, displaying the full contents of that text box in the tooltip (where perhaps it doesn't all fit in the confines of the text box). Here, we'll use the ToolTipService.ToolTip attached property (which you may remember being demonstrated back in Chapter 3, "An Introduction to XAML"), and bind it to the Text property of the text box using the Self mode of the RelativeSource markup extension:

<TextBox Text="{Binding Path=CurrentItem}"
                        ToolTipService.ToolTip="{Binding Text,
                                          RelativeSource={RelativeSource Self}}" />

The TemplatedParent mode is only applicable when the control is contained within a control template or a data template. It returns the templated item and enables the target property to be bound to a property on that item. When used inside a data template (such as the data template for a ListBox item), the TemplatedParent mode will return the content presenter for that templated item. Note that it doesn't actually return the ListBoxItem; the data template is actually being applied to the content presenter of the item, so it's the content presenter that will be returned (unlike when using a control template to template the ListBoxItem, where the TemplatedParent mode will return the ListBoxItem itself).

For example, the following binding expression in a data template will get the actual height of the content presenter:

"{Binding RelativeSource={RelativeSource TemplatedParent}, Path=ActualHeight}"

Another scenario where this binding may be useful in a data template is when you want to get the data context of the templated item. The data context is still inherited down the hierarchy in to data templates, but if you assign a different data context on a control in the data template (such as a Grid for example), you could use this method to obtain and bind to the original data context for the item again.

You can bind a property of a control to the binding source assigned to its DataContext property (either assigned directly to the property on the control or inherited down the object hierarchy), by simply setting its value to "{Binding}". This is a common scenario when binding a number of controls to the same inherited data context (e.g., the data context of a Grid control is bound to a collection, and multiple controls within that Grid inherit that data context and use it as their binding source). To bind the ItemsSource property of a ListBox control in the Grid to the collection, you can set its binding expression to "{Binding}".

You've seen how you can bind to a property on bound objects, resources, and other controls in the view, but what if the source of the property you want to bind to is actually the view's code-behind class? There's two ways you can go about this. The first is to bind the DataContext property of the root element in your XAML file to itself using the RelativeSource binding, like so:

DataContext="{Binding RelativeSource={RelativeSource Self}}"

This will get a reference to the code-behind class for the XAML file and bind the DataContext property to it, which will then be inherited down the object hierarchy. Any controls within that object hierarchy will therefore automatically use the code-behind class as their binding source. For example, if you have a property named UserName in the code-behind, displaying the value of that property in a TextBlock control within the view would therefore simply require the following XAML:

<TextBlock Text="{Binding UserName}" />

However, this method does have the pitfall of requiring that no controls further up in the object hierarchy have been assigned a different data context (overriding our RelativeSource binding with a different binding). If this is the case, there is another method you can use instead. Start by giving the root element in your XAML file a name (via its Name property). In this example we have named it ControlRoot. Now, you can simply use ElementName binding to assign that element as its binding source:

<TextBlock Text="{Binding UserName, ElementName=ControlRoot}" />

Start by creating the class that we will use as our binding source (generally you will have a ViewModels folder in your project for these classes), and name it ProductViewModel. Add some properties to it that we will bind to in the XAML (eg. Name, ProductNumber, etc):

public class ProductViewModel
{
    public string Name { get; set; }
    public string ProductNumber { get; set; }
}

For the purposes of experimentation, simply assign some hard-coded data to the properties on the class in the class's constructor. Alternatively, you can set the property values in the XAML when defining and instantiating it as a resource.

Now, declare a namespace prefix in your XAML file for the namespace where the class can be found:

xmlns:vm="clr-namespace:AdventureWorksLOB.ViewModels"

The next step is to define and instantiate the class as a resource:

<vm:ProductViewModel x:Key="productResource" />

You can also assign values to the properties on the class at this stage if required:

<vm:ProductViewModel x:Key="productResource" Name="Bike" ProductNumber="B001" />

Now, you can bind to this object resource (using the StaticResource markup extension to reference it) however you wish:

<TextBox Text="{Binding Name, Source={StaticResource productResource}}" />

Now that you've seen the manual way of defining the resource and creating controls that bind to it, there is a somewhat easier method to have these done automatically. Back in Chapter 6 - Implementing Summary Lists, you saw how to drag an entity (returned from the server via RIA Services) from the Data Sources window and onto the design surface, with that action automatically creating a DomainDataSource control to retrieve the data from the server and controls to display and edit the entity.

Although you won't find the class that you created listed in the Data Sources window, you can add it (via the Add New Data Source button) and then drag and drop it onto the design surface. A resource will be created (although it will be a CollectionViewSource wrapping a collection of the given objects, slightly different from what was demonstrated earlier), and controls will be created to bind to it. This method expects the source of the CollectionViewSource to be set in the code-behind, and you will find that by dragging the class from the Data Sources window onto the design surface automatically adds some (commented out) code to the code-behind demonstrating how to do so.

In this example, we'll bind to the objects contained within a PagedCollectionView collection view.

For this example, we will have a collection of Person objects, which are to be displayed in a ListBox control. We also have a TextBox control and want to show the name of the selected person in the list box in it (with the text changing in the text box whenever a new item is selected in the list box). Figure 10-2 demonstrates the final output.

Figure 10.2. The output from this example (with minor embellishments)

public class Person
{
    public string Name { get; set; }
}

public class SampleData
{
    public PagedCollectionView PeopleView { get; set; }

    public SampleData()
    {
        List<Person> people = new List<Person>();
        people.Add(new Person() { Name = "Homer" });
        people.Add(new Person() { Name = "Marge" });
        people.Add(new Person() { Name = "Bart" });
        people.Add(new Person() { Name = "Lisa" });
        people.Add(new Person() { Name = "Maggie" });
        PeopleView = new PagedCollectionView(people);
    }
}

<models:SampleData x:Key="sampleDataResource" />

<StackPanel DataContext="{Binding Path=PeopleView,
                                  Source={StaticResource sampleDataResource}}">
    <ListBox ItemsSource="{Binding}" DisplayMemberPath="Name"

Height="120" Width="120" />
    <TextBox Text="{Binding Name}" Width="120" />
</StackPanel>

In the last example, we implemented a collection view using a PagedCollectionView collection view, but this time we will use a CollectionViewSource view proxy instead. You may remember (from Chapter 6 - Implementing Summary Lists) that unlike the PagedCollectionView (which is a collection view), the CollectionViewSource isn't actually a view as such, but a view proxy. You assign a collection to its Source property, and it provides a corresponding collection view from its View property (in the form of a ListCollectionView). Let's return a CollectionViewSource view proxy from our SampleData class now instead of a PagedCollectionView collection view:

public class SampleData
{
    public CollectionViewSource PeopleViewSource { get; set; }

    public SampleData()
    {
        List<Person> people = new List<Person>();
        people.Add(new Person() { Name = "Homer" });
        people.Add(new Person() { Name = "Marge" });
        people.Add(new Person() { Name = "Bart" });
        people.Add(new Person() { Name = "Lisa" });
        people.Add(new Person() { Name = "Maggie" });

        PeopleViewSource = new CollectionViewSource();
        PeopleViewSource.Source = people;    }
}

You can still bind to the objects exposed by this collection view proxy in exactly the same way as we did with the PagedCollectionView collection view:

<StackPanel DataContext="{Binding Path=PeopleViewSource,
                                  Source={StaticResource sampleDataResource}}">
    <ListBox ItemsSource="{Binding}" DisplayMemberPath="Name"
             Height="120" Width="120" />
    <TextBox Text="{Binding Name}" Width="120" />
</StackPanel>

However, once again, you probably will find this binding somewhat confusing (as it was when binding to the PagedCollectionView collection view), but this time for a different reason. Unlike the PagedCollectionView, which is itself a collection view, the CollectionViewSource is not a collection view - it is a collection view proxy. To get to the view itself, we should have to go via its View property (for the ListBox binding), and to get to the current item we should have to access its View.CurrentItem property! However, we are doing neither in the XAML above!

So once again, you may be wondering what's going on here, but you will find that that answer is pretty much the same. This time, the binding engine recognizes that it is binding to a CollectionViewSource, and assumes that it's not the CollectionViewSource itself that you want to bind to, so it automatically drills down to its View property to get to the collection view to bind to (for the ListBox binding), and automatically drills down to its View.CurrentItem property to get to the object to bind to (for the TextBox binding). The CollectionViewSource essentially becomes transparent when binding to it, such that you are binding to the collection view that it exposes, rather than the CollectionViewSource itself.

Binding to a collection view, and particularly binding to a CollectionViewSource can be a confusing concept, but once you understand it, it makes the binding process simpler and more succinct.

<models:SampleData x:Key="sampleDataResource" />
<CollectionViewSource x:Key="peopleViewSource"
  Source="{Binding PeopleCollection, Source={StaticResource sampleDataResource}}" />

Back in Chapter 7, "Building Data Entry Forms," we covered the ability for formatting a bound property's value using the StringFormat property of the binding before it is passed to the target control to be consumed. As a recap, this can be a very useful feature when binding to a nonstring property (such as a DateTime, or a decimal). You can use the StringFormat property on the binding to set the format (using the same types of formatting strings as you would use if you were to format the value using its ToString method in code (using either standard or custom formats). For example, the following binding uses a standard formatting string to display the bound property's value in the text box formatted as currency:

<TextBox Text="{Binding TotalCost, Mode=TwoWay, StringFormat=C />

Or you can format a date as a long date (e.g., Sunday, May 16, 2010) using a standard formatting string:

<TextBox Text="{Binding StartDate, Mode=TwoWay, StringFormat=D />

format a date as a custom format (e.g., 2010-05-16) using a custom formatting string:

<TextBox Text="{Binding StartDate, Mode=TwoWay, StringFormat=yyyy-MM-dd />

You can also format a decimal, single, double, or float to a given number of decimal places (e.g., 3.14) using a custom formatting string:

<TextBox Text="{Binding PI, Mode=TwoWay, StringFormat=0.00 />

If you want to include commas or other special characters in your string format, enclose the formatting string within apostrophes (not quotes, as they are used to delimit the whole property assignment):

<TextBox Text="{Binding StartDate, Mode=TwoWay, StringFormat='MMM dd, yyyy' />

Alternatively, you can simply escape them by inserting a backslash () prior to the special character:

<TextBox Text="{Binding StartDate, Mode=TwoWay, StringFormat=MMM dd, yyyy />

If the value of a property being bound to is null, you can specify an alternate value to use instead using the TargetNullValue property of the binding. This is a useful feature when you are binding to a nullable type and want to provide a default value when one isn't provided, for example:

<TextBlock Text="{Binding TotalAmount, TargetNullValue=0 />

If the source of the binding is null (i.e., the value of both the DataContext property of the control and the Source property of the binding are null), or the property being bound to does not exist on the object assigned as the source of the binding, you can specify an alternative value to use instead using the FallbackValue property of the binding. For example, this binding will display "Oops!" if the binding source is null:

<TextBox Text="{Binding Name, Mode=TwoWay, FallbackValue=Oops! />

Back in Chapter 7, "Building Data Entry Forms," we discussed implementing the IEditableObject interface to add transaction type behavior to our classes (begin, accept, or cancel changes). However, you may not have the luxury of implementing this interface in the classes that you bind to, so rather than rolling back unwanted changes (the behavior that the IEditableObject interface enables), you could alternatively prevent changes being made to the object until you explicitly commit them (such as when the user clicks the OK button). This behavior can be enabled using the UpdateSourceTrigger property of the bindings. This property has an enumeration type with two possible values: Default and Explicit. Default (obviously) is the default value, where the source property of the binding is updated automatically by the binding when it has been changed via the user interface (usually once the control loses the focus). However, assigning Explicit as the value of this property means that in order for the source property of the binding to be updated, you must manually initiate the update.

Let's look at a simple example of enabling the user to update the name of a product via a text box:

<TextBox Name="NameTextBox" Text="{Binding Name, Mode=TwoWay}" />

By default, as soon as this text box loses the focus, the Name property on the bound object will be updated with the text entered in the text box accordingly. However, you can prevent this behavior by setting the UpdateSourceTrigger property of the binding to Explicit:

<TextBox Name="NameTextBox"
         Text="{Binding Name, Mode=TwoWay, UpdateSourceTrigger=Explicit}" />

Now, when the text box loses the focus, the bound value will not be updated. Say you have an OK button in the view, and you want to commit the changes made to the field back to the bound object when the button is clicked. To do so, you can handle the button's Click event in the code-behind and get the binding expression for the text box's Text property (using the GetBindingExpression method on the text box, which returns a BindingExpression object). You can then explicitly force the bound property of the binding to be updated using the UpdateSource method on the BindingExpression object, like so:

BindingExpression expr = NameTextBox.GetBindingExpression(TextBox.TextProperty);
expr.UpdateSource();

We've seen how you can format the bound value (using the StringFormat property of a binding) before passing it onto the target control, but what if you want to convert the value to a completely different value (given some predefined rules) instead? A perfect example is attempting to bind a Boolean value to the Visibility property of a control. This is not possible, because the Visibility property only accepts values from the Visibility enumeration (Visible or Collapsed). You could modify the property on the object that you are binding to in order to return a value from the Visibility enumeration instead, but this is not always possible (or ideal). There is, however, a way we can transform the Boolean value to a Visibility enumeration as a part of the binding process, and that's using a value converter.

A value converter is a class that implements the IValueConverter interface (from the System.Windows.Data namespace), which has two methods:

public class BoolToVisibilityValueConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter,
                            System.Globalization.CultureInfo culture)
    {
        return (bool)value ? Visibility.Visible : Visibility.Collapsed;
    }

    public object ConvertBack(object value, Type targetType, object parameter,
                                System.Globalization.CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

xmlns:vc="clr-namespace:AdventureWorksLOB.ValueConverters"

<vc:BoolToVisibilityValueConverter x:Key="VisibilityConverter" />

<Button Content="Save" Height="23" Width="75"
   Visibility="{Binding IsDirty, Converter={StaticResource VisibilityConverter}}" />

public class EnumEqualityValueConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter,
                            System.Globalization.CultureInfo culture)
    {
        return value.ToString() == parameter.ToString();
    }

    public object ConvertBack(object value, Type targetType, object parameter,
                                System.Globalization.CultureInfo culture)
    {
        return Enum.Parse(targetType, parameter.ToString(), true);
    }
}

<RadioButton Content="&lt; 20" IsChecked="{Binding AgeBracket, Mode=TwoWay,
    Converter={StaticResource EnumConverter}, ConverterParameter=BelowTwenty}" />
<RadioButton Content="20 to 29" IsChecked="{Binding AgeBracket, Mode=TwoWay,
    Converter={StaticResource EnumConverter}, ConverterParameter=Twenties}" />
<RadioButton Content="30 to 39" IsChecked="{Binding AgeBracket, Mode=TwoWay,
    Converter={StaticResource EnumConverter}, ConverterParameter=Thirties}" />
<RadioButton Content="40 Plus" IsChecked="{Binding AgeBracket, Mode=TwoWay,
    Converter={StaticResource EnumConverter}, ConverterParameter=FourtyPlus}" />

public class FullNameValueConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter,

System.Globalization.CultureInfo culture)
    {        Person person = value as Person;
        return person.FirstName + " " + person.Surname;
    }

    public object ConvertBack(object value, Type targetType, object parameter,
                                System.Globalization.CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

As mentioned back in Chapter 3, "An Introduction to XAML," Visual Studio 2010 provides a data binding expression builder (from the Properties window), which can be of help when learning how to write data binding expressions. This data binding expression builder will lead you through the process of creating a data binding expression.

Select the target control in the designer, find the target property that you want to bind to in the Properties window, and click the Advanced Properties icon next to its name. Select the Apply Data Binding menu item from the popup menu (as shown in Figure 10-3).

Figure 10.3. Opening the data binding expression builder

This will open the data binding expression builder as a pop-up window (as shown in Figure 10-4). Note that the builder has an accordion style layout, where you click each header to open the corresponding pane and select the options. The first step is to select a source for the binding.

Figure 10.4. Selecting a data binding source

The next step is to select a path for the binding (as shown in Figure 10-5).

Figure 10.5. Selecting a path to bind to on the source

If you wish, you can select a value converter to use in the binding, as shown in Figure 10-6.

Figure 10.6. Selecting a value converter for the binding

The final step is to select any additional options that should be applied to the binding, as shown in Figure 10-7.

Figure 10.7. Selecting additional (miscellaneous) binding options

After selecting the options, simply clicking somewhere outside the data binding expression builder pop-up will close it and apply the generated binding string to the control property.

It is very easy to make a mistake (such as misspelling a property name in the path of the binding) when creating a binding or break a working binding when you refactor a class that acts as a binding source (such as renaming a property). At other times, bindings simply don't work in the way you would expect.

These types of data binding errors can be particularly hard to track down at times (and it can be hard to even recognize that they exist), as when bindings fail, they fail silently without throwing an exception in the application. There are, however, some techniques you can use to help you identify and track down data binding errors, which we'll take a look at here.

The first method is to simply take a look at the Output window in Visual Studio (select View ~TRA Output from the main menu if you can't find it). Binding errors are logged to the Output window when the application is being debugged, with a corresponding error message, the binding source object and property, and the binding target control and property. For example, by setting the binding path to the Nam (a misspelling) property instead of Name, will result in the following error being logged to the Output window:

System.Windows.Data Error: BindingExpression path error: 'Nam' property not found on 'AdventureWorksLOB.Models.Product' 'AdventureWorksLOB.Models.Product' (HashCode=29083993). BindingExpression: Path='Nam' DataItem='AdventureWorksLOB.Models.Product' (HashCode=29083993); target element is 'System.Windows.Controls.TextBox' (Name='NameTextBox'), target property is 'Text' (type 'System.String')..

This provides you with a fair amount of information about the error, which, in most cases, will help you track it down.

Unfortunately, in nondebugging scenarios, you cannot use this technique. An option is to assign a value to the FallbackValue property of the binding. Although it doesn't tell you why the binding failed, it can help prove that the binding did fail:

<TextBox Text="{Binding Name, Mode=TwoWay, FallbackValue=Binding failed!}" />

You could alternatively use the helper created by Karl Shifflett (creator of the XAML Power Toys, detailed back in Chapter 7, "Building Data Entry Forms") which he has called Glimpse. One of its features is displaying bindings that have no source. You can get more details about Glimpse and download it at http://karlshifflett.wordpress.com/2009/06/08/glimpse-for-silverlight-viewing-exceptions-and-binding-errors/.

Another trick you might like to try is to add a value converter to your binding and put a breakpoint in its Convert and ConvertBack methods. This will enable you to hook into the binding process and perhaps help you identify the issue that you are having with that binding.

Even if your bindings are hooked up correctly, they may fail for many other reasons. Here are just a few troubleshooting tips you may wish to check:

You can actually specify bindings using property element syntax. The following example demonstrates binding to a property named Name using property element syntax:

<TextBox>
    <TextBox.Text>
        <Binding Path="Name" />
    </TextBox.Text>
</TextBox>

At times, you want to bind a control property to multiple properties on the binding source object, taking each of those property values and merging them into a single value to be consumed by the target. This is known in WPF as a MultiBinding, but this feature is not available in Silverlight. Earlier in this chapter, we discussed combining the values of multiple properties together while data binding using a value converter, which is a way to get around this omission. That said, this method isn't that different to using a MultiBinding in WPF, as it requires the use of a value converter too. MultiBinding does have the advantage of being a slightly more generic solution (although you could make the value converter solution a little more generic by passing the names of the source properties to use in the converter parameter). Colin Eberhardt has created a means for implementing MultiBindings in Silverlight, which you can obtain at www.scottlogic.co.uk/blog/colin/2010/05/silverlight-multibinding-solution-for-silverlight-4/.