Matthias Shapiro

I need fewer hobbies

INotifyPropertyChanged Snippets (And Why You Should Use These Instead of DependencyProperties)

First things first, here are my INotifyPropertyChanged snippets.

INotifyPropertyChanged snippet (PropertyChangedEventHandler and RaisePropertyChanged method)

INotifyPropertyChanged Property snippet

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.

You see, there I was, minding my own business and trying to build some data to use with some XAML comps I was playing with and I was having some of the strangest things happen with my data. I had a DependecyProperty ObservableCollection in my ViewModel and I put a couple different views in my screen. (I was using an MVVM pattern, because that’s what all the kool kids are doing.)

Then, it suddenly seemed as if all my Views were sharing the same ObservableCollection, even though every other DependencyProperty they were bound to had unique values. So I did what I always do when I have problems like this… I ask Joe McBride.

It turns out I had gotten confused. I understood that DependencyProperties were good for the following:

  • Providing callbacks when the property is changed
  • Binding to stuff
  • Animations

I figured that this is the kind of behavior I wanted from my data. I was wrong. As it turns out that is the kind of behavior I want out of the properties that I use in my WPF and Silverlight controls. It seems that DependencyProperties are meant to be used with controls and not for stand-alone data.

For stand-alone data, I should have used INotifyPropertyChanged, which is an interface for… well… notifying things when a property changes. I already had handy snippets for creating DependencyProperties (thanks to Robby Ingebretsen). So I tweaked his snippets so that they work for INotifyPropertyChanged properties.

Because it seems silly to implement the PropertyChangedEventHandler in every class that needs notify-able properties, I like to create a "NotifyObject" class:

class NotifyObject : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected void RaisePropertyChanged(string propertyName)
    {
        var handler = PropertyChanged;
        if(handler != null)
        {
            handler(this, new PropertyChangedEventArgs(propertyName));
        }
    }       
}

Then, I can make my new class inherit from NotifyObject and away I go creating my bindable, notify-able data:

public class MyNotifyableData : NotifyObject
{
    public MyNotifyableData()
    {
    }

    #region MyProperty (INotifyPropertyChanged Property)
    private string _myProperty;

    public string MyProperty
    {
        get { return _myProperty; }
        set
       
{
            _myProperty = value;
            RaisePropertyChanged("MyProperty");
        }
    }
    #endregion
}

This property was created using my snippet above. Hope it helps.

This entry was posted in Advanced Tutorial, Binding, c#, How To..., Silverlight, WPF. Bookmark the permalink.

0 Responses to INotifyPropertyChanged Snippets (And Why You Should Use These Instead of DependencyProperties)

  1. I agree with Clayton Firth. This is a violation of pattern not checking the value being actually changed before raising notifications. There may be many components bound to this property or listening to property change notifications. You will make a great performance impact or push UI editors into the endless loop of updates and as a result StackOverflow exception.
    Checking the property value is a mandatory part of this pattern.

  2. Steve

    You shouldn’t give a new collection as default value for your dependency property. Create a new instance in the ctor and there should be no problem.

  3. Matthias Shapiro

    I assume that by “actually changes”, you mean that the new value is different than the old value (even if the value changed in the sense that it was re-set). What you have works for me… 🙂

  4. Clayton Firth

    What is you opinion of checking if the property “actually” changes? I would normally add the following code.

    if(!_myProperty.Equals(value))
    {
    _myProperty = value;
    RaisePropertyChanged(“MyProperty”);
    }