Flexible and Powerful Data Binding with WPF, Part 2

All applications are dependent on data in some form and most developers find themselves writing reams of data access code. Microsoft has been building databinding frameworks for years. Each one promises to solve our databinding woes forever. We’re still waiting for the perfect one. In the Nov/Dec 2008 issue of CoDe Magazine you were exposed to programmatically controlling data binding mechanisms of WPF. Along with a programmatic interface, WPF also provides a declarative databining interface. This second article will introduce you to using the declarative data binding mechanisms contained in WPF.

XAML Binding

It’s possible to set up a binding in XAML only. The XAML parser understands how to parse and instantiate many of the WPF framework classes. It doesn’t know how to work with non-WPF classes unless they are registered with the parser. Therefore, the first step in using a custom data source is to associate an XML namespace with a CLR namespace. The following XAML snippet shows how to set up an xmlns “sys” namespace for the System namespace in mscorlib and a “local” namespace for a custom assembly:

Next you need to create an instance of the type and store it in a discoverable location. In C#/Visual Basic you would create a variable and instantiate the type. In XAML you have to put the instance in a resources section. The XAML parser instantiates your type and adds the instance to the resource dictionary. You provide a key for the resource so that you can retrieve the instance later:

Now it is time to set up the binding in the main part of the page and employ the Source property for the configuration. Set the Source property to refer to an instance of an object, in this case the sample string declared in the Page.Resources section shown previously. Bind the first TextBlock directly to the string and use a Path for the second TextBlock to show the second Char in the String.Chars array:

The next example shows comparable XAML for binding to the Employee object:

Relative Source Binding

It’s not necessary or desirable to name every element in a WPF logical tree. This poses a problem when binding to other elements. Use the ElementName property to specify a named element as the source. There are times when you won’t know the element name but you’ll want to bind to it anyway.

Sometimes you just want to say; "Bind to my parent StackPanel" or "Bind to the previous item in this list". You may not know the names of these elements, but you want the data anyway. Another example is when you want to bind to a property on the same element. Could there be a way to configure this same element binding without requiring an element name?

Use the RelativeSource property when you need an element binding, but you can’t use the ElementName property. There are four modes available for RelativeSource bindings. I’ll explain two of the modes below (the other two aren’t relevant to this article):

Self: Reference any property on the current object. The next example shows some XAML that binds the TextBox Background property to the Text property on the same TextBox. Note the nesting of one markup extension within another in this example. Run the application and try typing “Red” or #FF336688 in the text box to see the background color change:

FindAncestor: Walk the tree of parent elements looking for a specific type of element. You must specify the AncestorType, a DockPanel in this example, for a successful binding. Use the AncestorLevel to skip over parent levels. For example setting AncestorLevel=2 will skip one generation. In the following example the TextBox Background will bind to the grandparent DockPanel and will be blue:

The other two RelativeSource modes are TemplatedParent and PreviousData, which are not relevant to this article.

Binding Direction

When you configure a binding you can influence the direction that the data flows. A common binding direction is from the source to the target. This is implemented with the BindingMode.OneWay enumeration setting. In a OneWay binding, the target property is updated when the binding source changes. Remember that change notification only happens if the data source object notifies WPF about the changes. See the Change Notification section earlier in this article for details.

OneWay direction is common if the target is a non-editable element like a TextBlock or Label. Since the user cannot change the value, it’s not necessary for the data to flow back to the source:

In a BindingMode.TwoWay binding, the target property is updated when the source property changes and vice versa. TwoWay is common when the target is an edit control like Slider or TextBox.

What if you don’t specify a value for the Mode property? What type of binding direction will you get? The answer is that it depends on the type author preferences. Each dependency property has a FrameworkPropertyMetadataOptions enumeration flag set. If you’ve set the BindsTwoWayByDefault value then the default is TwoWay, otherwise it will be OneWay. The TextBox default Mode is TwoWay. Most other controls are OneWay by default.

In a BindingMode.OneTime binding, the target property is updated once, when the system establishes the binding. The WPF dependency property system disconnects the binding after it sets the initial value and the system does not forward further changes. Usually you’ll use this mode to reduce overhead if you know the value won’t change in the source property.

In a BindingMode.OneWayToSource binding the data flows from the target property to the source property. It is still a single direction binding. In other words, no data flows back to the target. OneWayToSource exists to solve one particular problem in the WPF binding world. Data target properties are always dependency properties. There are no exceptions to this rule.

Occasionally you’ll run across an element that has a property that you want to use as a target, but you discover that it wasn’t implemented as a dependency property. The Run element is a classic example of this problem. A Run is a subsection of a FlowDocument. Run elements allow you to break a big document into manageable sections and apply formatting or modify the Run text from your code:

In the code behind, change the Run as shown here.

In C#:

In Visual Basic:

Now imagine that you want to bind a TextBox to the Run element. Sorry, you can’t do that with a OneWay or TwoWay binding. Since Run.Text is not a dependency property, you’ll have to use a OneWayToSource binding instead. Here’s some XAML that demonstrates this binding:

By: Walt Ritscher

Walt Ritscher has trained thousands of corporate developers during the last twelve years. An active speaker, his teaching schedule has taken him throughout the world providing developer training at corporations, universities, and software conferences. He has collaborated on several books and videos published for the developer market including early adopter .Net courses at Microsoft Press. Walt is currently consulting and teaching .NET and WPF classes for Wintellect. Walt's industry expertise has placed him on various national technology advisory boards. He is also deeply involved in the local developer community-founding the .NET Developers Association in Redmond, WA. Walt has accumulated plenty of experience as a developer and is currently a Microsoft MVP and a member of the Silverlight Insiders. As a Web programmer he has worked numerous projects including: EPA sites and the Microsoft Community Starter Kit.

waltonline@scandiasoft.com