Search

As I’ve been developing more complex Silverlight business applications, I’ve been increasingly relying on BackgroundWorker to offload complex calculations and operations to the background thread.

Something I didn’t have to worry about in the typical user interface thread-only implementation of my app was which thread change notifications fire on.

If you are writing ViewModels you will probably need to implement INotifyPropertyChanged, so this article of Brian Genisio might be the right choice to learn a few things about it.

I spend a lot of time writing ViewModels, which almost always implements INotifyPropertyChanged.  For those who are not familiar with this interface, it includes a single event: PropertyChanged.  That event contains a payload of the name of the property that changed.  It exists as a standard way to notify observers that a property needs to be re-evaluated.

Although I use it all the time, I have always believed that INotifyPropertyChanged has some serious shortcomings.  One of those shortcomings deals with dependant properties. 

Silverlight classes rely on the INotifyPropertyChanged interface and associated PropertyChanged event it contains to ensure that data binding stays up-to-date in an application.  It’s a great feature because you don’t have to worry about ensuring that changes to object properties are propagated back to controls….Silverlight handles refreshing control values for you automatically as long as the class that’s being data bound implements INotifyPropertyChanged and property set blocks raise the event.  I use a fairly standard pattern for defining my properties and raising property changed events (there are several options for doing this…see a nice list here). 

Just download them into your "Visual Studio 2008CodeSnippetsVisual C#My CodeSnippets" folder and they should work. Just type "notify" and intellisense should show you "notifyo" (for NotifyObject) and "notifyp" (for NotifyProperty). Hit tab twice and the code should dump into your project.

This is definitely a "use at your own risk" project.

In a previous post Colin Eberhardt demonstrated a technique for binding a Silverlight DataGrid to dynamic data. With his next blog post Colin extends the previously described method by adding change notification.

In my previous blog post I described a method for solving the commonly faced problem of binding a Silverlight DataGrid to dynamic data, the form of which is not know at compile time. This blog post extends on the method previously described, adding change notification, allowing the DataGrid to synchronise the UI with changes to the bound data and to allow the user to edit the DataGrid’s contents.

I just read an article by Micheal Sync about implementing property changed notifications with Expression Tree, I liked what I saw but didn't appreciate the inheritance requirement (as always). So I quickly whipped up three alternate way using extension methods.

INotifyPropertyChanged interface is used to notify that a property has been changed and thus to force the bound objects to take the new value.

C#

public class Client : INotifyPropertyChanged

{

    private string name;

    public event PropertyChangedEventHandler PropertyChanged;

    public string Name

    {

        get

        {

            return this.Name;

        }

        set

        {

            if ( this.name == value )

                return;

            this.name = value;

            this.OnPropertyChanged( new PropertyChangedEventArgs( "Name" ) );

        }

    }

    protected virtual void OnPropertyChanged( PropertyChangedEventArgs e )

    {

        if ( this.PropertyChanged != null )

            this.PropertyChanged( this, e );

    }

}

Note that the value is changed only if the new value is different. Thus we prevent the firing of the PropertyChanged event when the actual value is not changed.

Alternative way is to provide changed event for each property.

That's it!