Binding to a single object.

On February 5, 2009February 6, 2009 By peteohanlonIn INotifyPropertyChanged, Microsoft, user control, Windows Presentation Foundation17 Comments

So today, on CodeProject, one of the WPF regulars posed a question about whether or not you could only bind to ObservableCollection objects, and if you could bind to single objects, how could you guarantee two way databinding goodness. As you may well imagine, I promptly answered that you could indeed bind to a single object and implement two way databinding with it. The discussion also posed the question, could WPF bind to properties that linked into child objects and display these – from separate usercontrols.

This seemed to me to be an ideal candidate for demonstrating the beauty and wonder that is the WPF databinding infrastructure. If you’ve only ever been exposed to WinForms or ASP.NET databinding, then you are in for a major treat – WPF (and Silverlight) provide so much more bang for your buck with binding that it’s hard to see how we managed before. First of all, let’s take a look at our business object classes, Benefit and Customer. Both of these classes implement INotifyPropertyChanged so that we get access to the notification mechanism that supports two way binding.

First of all, here’s Benefit.cs:

And here’s Customer.cs:

As you can see, there’s nothing out of the ordinary in these classes – they don’t do anything clever. They are just your bog standard, basic model classes.

Now, here’s the main window XAML:

The TextBoxes are bound to the relevant entries in the Customer class using the familiar {Binding Path=…} syntax. But wait, where’s the Benefit class in all this? I added it for a reason, yet there’s no sign of it. Well, as you can see – there’s a reference to a UserControl (BenefitsControl), and we are going to perform the actual binding in this class. Here’s the definition of BenefitsControl.xaml:

Look – there’s the binding Benefits.ProviderName, but would it surprise you to know that I’m not going to put the data class anywhere near this control. I’m going to set the DataContext on the parent control and let the usercontrol “find” the data there. Here’s the implementation of the code behind the parent XAML (Window1.cs):

So – here’s the application in all its glory:

Well – now that we’ve covered the code, how does the databinding actually work? How does the user control actually get its binding to work? This is where the wonder that is WPF actually comes into play. If the binding can’t find data in the data context at the current level, it works its way back up the logical tree until it can. Seriously – I love this stuff, and I’d hate to go back from it.

The code for this application can be downloaded here. Note that you’ll need to change the extension from .doc to .zip.

customerboundsamplezip

The notification gotcha.

On October 22, 2008 By peteohanlonIn INotifyPropertyChanged, Windows Presentation Foundation2 Comments

When your application uses DataBinding in WPF, it’s great how little you actually have to do to have full two-way databinding running, with multiple views watching the same data, and reacting based on data changes. This amazingly powerful feature is, to me, one of the key selling features of WPF and Silverlight; no longer do you have to write huge amounts of code in your Windows Forms or ASP.NET application to manage all the different views on the same data. The underlying platform takes care of it for you.

One of the key components in this “magic”, is the use of INotifyPropertyChanged, which is responsible for notifying the data consumers that properties have changed. In your property setter, all you need to do is call the PropertyChanged event, telling it which property has changed and off you go – support for two-way databinding. This means that the following code is a common site

On the surface, there doesn’t appear to be much wrong with it, but there is a flaw with this approach. What happens if your value doesn’t change, but the setter is called – this can happen if the user retypes a value that is already in the field for instance, WPF will trigger the setter even though nothing has changed, which results in the PropertyChanged event being raised, triggering rebinds. In a desktop application, this normally isn’t that significant, but it could be much more significant in a Silverlight app with heavy data binding. We know what the problem is, the Change method being called when nothing has changed, and the fix is easy. Check to see if the old value of the property differs from the new value, and call the Changed method only when they do. This simple change means that databindings only occur when something has actually changed.

Reusable transaction handling in WPF with IEditableCollectionView.

On October 21, 2008 By peteohanlonIn IEditableCollectionView, IEditableObject, INotifyPropertyChanged, Windows Presentation Foundation1 Comment

One of the banes of my life as a professional developer is handling grid editing where it can react intelligently to the user cancelling a change in the middle of an add or edit. Fortunately, if you know where to look, .NET can do a lot of the heavy lifting for you. With a little bit of IEditableObject goodness and a couple of helper classes, it’s now easy to add change handling to your WPF applications.

The attached project contains a library with two classes in it that you can use to do the work for you. The first class, EditableObject, manages the commit and rollback phases. The behaviour of this class is interesting, so I’d like to take a few minutes to go over it with you. The first thing to note is that it’s abstract, so your data classes inherit from it. When you start an add or edit operation, a copy of the current data class is created and the values are stored in the copy before the edit can progress. This gives us a copy to go back to without having to manually copy fields out. It uses reflection to do this, which can be a little bit slow on complex types, but when you’re dealing with reflecting on one object it’s not too bad and it was a compromise I was prepared to live with in return for the flexibility it provides.

Important note: As we’re using reflection here, I’m only serializing the fields of the current object so the hierarchy doesn’t get traversed. This means that your dataclasses must derive from EditableObject directly in order to get access to all the features of this wrapper.

EditableObject implements the INotifyPropertyChanged interface with a bit of a twist. In normal operations, you would raise the PropertyChanged event as soon as you changed the property, but we don’t want this to happen until we’ve committed the edit/add. This means we have to step outside the normal behaviour a little bit, and to do this I’ve changed the usual implementation of INotifyPropertyChanged so that it just records the properties that have changed – then it plays them back when the edit is committed. Obviously, if it’s rolled back then the notification doesn’t go ahead.

The second class, EditableCollectionHandler, encapsulates IEditableCollectionView which was introduced in .NET 3.5 SP 1. Basically, this is a view that supports adding, editing and removing items from a collection. The add and edit are transactional, so we can hook this up to EditableObject directly. It provides the following methods, Add, Edit, Remove, CommitChanges and CancelChanges as well as two properties; DefaultView and EditView.

In the sample, I’ve created a ListBox inside a grid. The grid contains two DataTemplates to be used with the ListBox, the default template used to display the data, and the EditTemplate, to be used when we are adding or editing a line of data.

When you set up the link from your WPF application to EditableCollectionHandler, you specify the object you want the collection view to work against, the container of the templates and the type of item you want to specify for editing the items when you are adding or editing. You also set up the name of the default template and the edit template (if you have one), and then you’re good to go.