views:

620

answers:

2

Hi, this question is going to show my lack of understanding of the expected behavior when implementing/using INotifyPropertyChanged:

The question is - for binding to work as expected, when you have a class which itself implements INotifyPropertyChanged, that has nested properties of type INotifyPropertyChanged are you expected to internally subscribe to change notification for these properties and then propogate the notifications? Or is the binding infrastructure expected to have the smarts to make this unnecessary?

For example (note this code is not complete - just meant to illustrate the question):

   public class Address : INotifyPropertyChanged
    {
       string m_street
       string m_city;

       public string Street
       {
          get { return m_street; }
          set
          {
             m_street = value;
             NotifyPropertyChanged(new PropertyChangedEventArgs("Street"));
          }
       }

       public string City
       {
          get { return m_city; }
          set 
          {
             m_city = value;
             NotifyPropertyChanged(new PropertyChangedEventArgs("City"));
          }
       }

    public class Person : INotifyPropertyChanged
    {
       Address m_address;

       public Address
       {
          get { return m_address = value; }
          set
          {
             m_address = value;
             NotifyPropertyChanged(new PropertyChangedEventArgs("Address"));
          }
       }
    }

So, in this example we've got a nested Address object in a Person object. Both of which implement INotifyPropertyChanged so that alteration of their properties will result in transmission of property change notifications to subscribers.

But let's say using binding someone is subscribing to change notification on a Person object, and is 'listening' for changes to the Address property. They will receive notifications if the Address property itself changes (a different Address object is assigned) but WILL NOT receive notifications if the data contained by the nested address object (the city, or street) are changed.

This leads to the question - is the binding infrastructure expected to handle this, or should I within my implementation of Person be subscribing to change notifications on the address object and then propagating them as changes to "Address"?

If you get to this point, thanks for just taking the time in reading this long winded question?

Comment much appreciated!

Phil

+1  A: 

You answered this question when you said

...say using binding someone is subscribing to change notification on a Person object,

That someone is subscribing to Person and has no way to know if Address has changed. So you will have to handle this situation on your own (which is quite easy to implement).

P.K
Is that really the case? For example in WPF, I could do this<StackPanel DataContext="{Binding thePerson}" Orientation="Vertical"> <StackPanel Orientation="Horizontal"> <Label Content="Street"/> <TextBox Text={Binding Address.Street}/> </StackPanel> <StackPanel Orientation="Horizontal"> <Label Content="City"/> <TextBox Text={Binding Address.City}/> </StackPanel></StackPanel>Here, (if I'm correct!), the binding infrastructure would make sure that the city and street textboxes are updated if either the Address property changes or the Street/City changes.
Phil
Sorry that xaml didn't come out too well in the comment. Anyway, what I'm trying to say is that it *could* be the requirement of the caller (the entity using the Person object) to register for change notifications on both the person object, and any nested property objects *which the caller uses*.I'm not saying that this is the case!... That's why I ask the original question because I believe it is possible for two designs (either push responsibility onto the user or onto the implementer).I've tried looking at MS documentation but haven't found anything definitive.Cheers!
Phil
I am sorry, assumed that you are using Winfomrs. I don't have much knowledge of WPF, but, my guess is that in WPF too it will work exactly the same way. WPF does have concept of events that bubble up and you will probably have to utilize that fact. Look at this article, it should explain you to create custom routed eventshttp://msdn.microsoft.com/en-us/library/ms742806.aspx
P.K
Thanks PK, I have used routed events and dependency properties but they don't really apply to what I'm using. I'm using the MVVM approach for WPF applications (if you do some WPF, highly recommend looking into it - it's kind of a specific variant of MVP for WPF, but very powerful because of the data driven UI of WPF).With the MVVM approach, there's two alternatives for change notification - WPF dependency properties or INotifyPropertyChanged. It's generally better to use Inotify since it's applicable to any class (no inheritance requirements).Thanks!
Phil
A: 

One of the simplest ways to do it is to add an event handler to Person which will handle notification events from m_address object:

public class Person : INotifyPropertyChanged
{
   Address m_address;

   public Address
   {
      get { return m_address = value; }
      set
      {
         m_address = value;
         NotifyPropertyChanged(new PropertyChangedEventArgs("Address"));
         m_address.PropertyChanged += new PropertyChangedEventHandler( AddressPropertyChanged );
      }
   }
   void  AddressPropertyChanged( object sender, PropertyChangedEventArgs e )
   {
       NotifyPropertyChanged(new PropertyChangedEventArgs("Address"))
   }
}
tkola
tkola, I know how to implement property change notification for children. The question is, is this required for data binding to work correctly. From what I've seen, the answer appears to be No - you do not need to perform change notification when child object change: it is effectively already handled by the binding infrastructure (at least for WPF)
Phil
You might want to unsubscribe from the old m_address's PropertyChanged event before setting m_address to a new value in Address set.
Ben Gribaudo