IPropertyChanged implementation, best practice

[TEK]

Hello

I'm having some questions regarding the implementation of
IPropertyChanged interface.

Status:
I have the basic stuff up and running, and on every property change I
get a call to my OnPropertyChanged method with the correct property
name.

Now I have two situations I'm interested in covering:

1) Raising indirect change events:
This issue occure when you for example have a calculated value and you
also need to notify when that property changed. Is there any best way
of doing this?
See Sum class below for one example that I do not think is very good,
but perhaps the only way?

2) Handling general Change event and optimized change handling:
It's normal to give one general Change event for dependent classes to
listen on, instead of having them to listen to spesific properties. It
might for example be that the listening class should update it's view
on data independent on what event is triggered. Another issue is that
you may want to optimize the event triggering.
I know that I will be modifying 50 of the properties on my object. It
is unessesarly that the any listening components should get 50 events.
So I would like to "buffer" the events and then just pass out one
single events that tells all listeners that they should refresh their
views.
Is there any way of doing this? For example, is there any general
property that all entities should be listening to that indicates that
just any property might have been changed.?

Regards, TEK


Examples, issue 1):
class Sum{
public int Arg1{
get{return _arg1;}
set {
if(value != _arg1){
_arg1 = value;
OnPropertyChanged("Arg1");
}
}

// arg2 implemation is equal to arg1

public int Total{
get{return _arg1 + _arg2;}
}

protected void OnPropertyChange(string propertyName){
if(propertyName == "Arg1" || propertyName == "Arg2")
OnPropertyChanged("Total");
if(PropertyChanged != null)
OnPropertyChanged(new PropertyChangedEventArg(propetyName))
}

}

 

[Nicholas Paldino [.NET/C# MVP]]

TEK,

I'm assuming you are speaking about the INotifyPropertyChanged
interface. The IPropertyChanged interface was the old name of the
interface. See inline:

1) Raising indirect change events:
This issue occure when you for example have a calculated value and you
also need to notify when that property changed. Is there any best way
of doing this?
See Sum class below for one example that I do not think is very good,
but perhaps the only way?

If you are binding to the Total property, and to the Arg1 property as
well, you should be firing two change events, actually. The first would be
the changing of the Arg1 property, the second is for the Total property.
Personally, I think it is better to have the code that fires the events in
the property itself, using a utility method. This way, the logic of which
event to fire is associated with the code that caused the change.

2) Handling general Change event and optimized change handling:
It's normal to give one general Change event for dependent classes to
listen on, instead of having them to listen to spesific properties. It
might for example be that the listening class should update it's view
on data independent on what event is triggered. Another issue is that
you may want to optimize the event triggering.
I know that I will be modifying 50 of the properties on my object. It
is unessesarly that the any listening components should get 50 events.
So I would like to "buffer" the events and then just pass out one
single events that tells all listeners that they should refresh their
views.
Is there any way of doing this? For example, is there any general
property that all entities should be listening to that indicates that
just any property might have been changed.?

No, there is no way to do this. The IPropertyChanged interface is for
property-level changes, not to indicate that the whole class should be
re-bound to.

Hope this helps.