You can do a lot with the techniques for data binding that we discussed in Hour 6. However, you will find that you frequently need to format, or convert, the data that you are binding. For example, if you are binding a DateTime value to a TextBlock, you’ll want to control how the date is rendered. Should it render as 5/22/1998 or as May 22nd, 1998?

The situation is even more complicated when you are binding to collections. Suppose that you want to filter a collection that you have bound to a ListBox. You don’t want to filter the actual underlying collection, just what is rendering in the control. A problem also occurs when you add or remove items from a collection. Most enumerables don’t provide any notification to the data bindings when items are added or removed.

In Hour 13, we wrote the following method on the code-behind for Shell.xaml that was responsible for adding tabs to the interface.

public void AddTab<T>(PresenterBase<T> presenter)
{
    TabItem newTab = null;

    for (int i = 0; i < tabs.Items.Count; i++)
    {
        TabItem existingTab = (TabItem)tabs.Items[i];

        if (existingTab.DataContext.Equals(presenter))
        {
            tabs.Items.Remove(existingTab);
            newTab = existingTab;
            break;
        }
    }

    if (newTab == null)
    {
        newTab = new TabItem();

        Binding headerBinding = new Binding(presenter.TabHeaderPath);
        BindingOperations.SetBinding(
            newTab,
            TabItem.HeaderProperty,
            headerBinding
            );

        newTab.DataContext = presenter;
        newTab.Content = presenter.View;
    }

    tabs.Items.Insert(0, newTab);
    newTab.Focus();
}

This method programmatically binds some data to the header on the tab. Let’s outline the logic inside this method.

The code for binding the tab header is a bit tricky, so let’s dig into it further. The Binding class is analogous to the Binding markup extension. It’s an entity in and of itself that represents the relationship between the source and the target of the data binding. The constructor for Binding accepts a path to the target. The path tells the binding how to get the target data, starting from the data context of the source. In this code, the path is provided from the presenter.

If we examine the constructor of ContactListPresenter, we’ll see that we set the value of TabHeaderPath to TabHeader. In this context, the code

Binding headerBinding = new Binding(presenter.TabHeaderPath);

is equivalent to the markup extension {Binding Path=TabHeader}. All the parameters you find on the markup extension are properties on the Binding class.

Keep in mind that we are setting the data context of newTab to the presenter. This means that it will look on the instance of ContactListPresenter for a property named TabHeader. We wrote this property to return the string All Contacts.

BindingOperations is a utility class used for manipulating bindings. We use the SetBinding method to establish the relationship between the tab and the presenter. SetBinding takes three parameters. The first is the target of the data binding. The second is the dependency property on the target that we are binding to. (Recall that dependency properties are available as static members on their parent class.) The third parameter is the binding we just created.

In summary, there are three steps to create a functioning data binding:

Before we move on, let’s consider how the tab binding works with EditContactPresenter. When we examine its constructor we see that it is setting TabHeaderPath to Contact.LookupName. Because EditContactPresenter has a property Contact of type Contact, this binds the tab’s header to the LookupName property on the presenter’s Contact property. Furthermore, Contact implements INotifyPropertyChanged. This means that any updates to the Contact.LookupName are immediately reflected in the tab header.

In practice, you rarely need to manipulate bindings programmatically. However, from time to time you will encounter situations such as this that do require it.

As we mentioned in Hour 6, for data binding to work, the source of the data must communicate any changes to the binding. The three methods of communication we discussed in Hour 6 are shown in Table 15.1.

These three approaches are primarily concerned with properties changing on single instances of an object. How do we handle the situation when we are adding or removing items from a collection?

In general we are talking about classes that implement IList or IList<T>. These classes have Add and Remove methods for changing the contents of the collection. The classes that ship with .NET that implement these interfaces don’t include a mechanism for change notification. On the whole that’s what we want, because change notification is expensive.

WPF includes the INotifyCollectionChanged interface to help us solve the problem. It is the sibling of INotifyPropertyChanged. Even better, WPF includes a default implementation of this interface, a generic class, ObservableCollection<T>.

You probably will never use INotifyCollectionChanged. With the advent of generics, it’s pretty rare that we ever need to implement our own collections. ObservableCollection<T> provides all the functionality that you’ll generally need.

In Hour 13, we added a field to ApplicationPresenter:

private ObservableCollection<Contact> _currentContacts;

Then in the constructor, we initialized _currentContacts, like this:

_currentContacts = new ObservableCollection<Contact>(
    _contactRepository.FindAll()
    );

You can pass in an instance of List<T> into the constructor of ObservableCollection<T>. This is very handy because most of the time we care to use only an ObservableCollection<T> in the presentation layer.

We’ve mentioned more than once the need to format or convert data when binding it to the UI. When working with data bindings in WPF, you can use a converter to transform the data. Converters are used to format data being displayed in the UI, but they can also be used to translate user input into the desired format.

We’ll demonstrate this with the telephone numbers we use in the Contact Manager. For example, we would like to consistently display telephone numbers in one of the following formats, depending on the number of digits provided:

We’d also like to store the phone numbers in a consistent format. We’ll keep it simple and store just the digits.

Converters are classes that implement IValueConverter. The interface has two methods, Convert and ConvertBack. Convert is used when data flows from the source to the target. ConvertBack is used when data flows back to the source (in a two-way binding).

Both methods take four parameters. The first is value, and it is the actual data to be manipulated. The second is the type of the target data. The third is for general use and can be used to parameterize your converter. We’ll discuss it later. The fourth is the cultural information about the executing context.

Let’s implement a class for handling telephone numbers in the Contact Manager:

Let’s review the logic in the Convert method:

string filteredResult = string.Empty;

foreach (char c in result)
{
    if (Char.IsDigit(c))
        filteredResult += c;
}

var filterQuery = from c in result
          where Char.IsDigit(c)
          select c;

string filteredResult = new string(filterQuery.ToArray());

using System;
using System.Globalization;
using System.Windows.Data;

namespace ContactManager.Presenters
{
    public class PhoneConverter : IValueConverter
    {
        public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
        {
            string result = value as string;

            if (!string.IsNullOrEmpty(result))
            {
                string filteredResult = FilterNonNumeric(result);

                long theNumber = System.Convert.ToInt64(filteredResult);

                switch (filteredResult.Length)
                {
                    case 11:
                        result = string.Format("{0:+# (###) ###-####}", theNumber);
                        break;
                    case 10:
                        result = string.Format("{0:(###) ###-####}", theNumber);
                        break;
                    case 7:
                        result = string.Format("{0:###-####}", theNumber);
                        break;
                }
            }

            return result;
        }

        private static string FilterNonNumeric(string stringToFilter)
        {
            if (string.IsNullOrEmpty(stringToFilter)) return string.Empty;

            string filteredResult = string.Empty;

            foreach (char c in stringToFilter)
            {
                if (Char.IsDigit(c))
                    filteredResult += c;
            }

            return filteredResult;
        }

        public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
        {
            return FilterNonNumeric(value as string);
        }
    }
}

public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
    string formattedText = parameter as string;
    if (string.IsNullOrEmpty(formattedText)) return value;
    return string.Format(formattedText, value);
}

{Binding Path=OfficePhone, Converter={StaticResource phoneConverter}, ConverterParameter='TEL:{0}'}

string.Format("TEL:{0}", OfficePhone);

This is a topic that really confused me when I first encountered it. I think it’s best to start by considering the problem we need to solve. In our Contact Manager, we have a collection of contacts. Specifically, we are working with an ObservableCollection<Contact> on the ApplicationPresenter. Both the sidebar and the list view bind directly to this collection. Additionally, when we add a contact we are inserting it into this collection. So far, this is what we want because changes produced in one part of the application are immediately reflected in other parts.

Now imagine that we want to filter the contacts on the sidebar, or perhaps sort the contacts in the list view. If we change the collection, it changes everywhere, and that’s not what we want. We don’t want sorting in the list view to affect the sidebar.

The solution is to use an intermediary object, or a collection view. The CollectionView class is part of WPF and acts as a wrapper around the collection we are interested in manipulating. The collection view tracks additional information about the collection, such as sorting, filtering, and grouping currently selected items.

Fortunately, WPF automatically uses a collection view whenever we bind to a collection. This is what enables a ListBox, or any item control, to track what is currently selected. That means we don’t have to solve the problem ourselves. The solution is built in to the framework!

WPF uses three types of collection views depending on the underlying collection. Table 15.2 lists the three types.

It’s important to understand that a collection view does not change the underlying collection. This means that you can have multiple views of the same collection and they don’t interfere with one another. Two ListBox controls bound to the same collection track their currently selected items independently.

We covered a lot of ground in this hour. You should now have a basic understanding of how to create and manipulate bindings in code. We used converters to help us format our telephone numbers; we used data templates to link buttons to contacts; and we demonstrated how we can apply sorting through the use of collection views.

Even so, there’s still a lot more that you can do with data binding.