Implementing PropertyChanged Event Ideas

[John Baro]

I need to implement an event to notify when a property has changed.

Method 1.
If I use a generic PropertyChanged event from System.ComponentModel then it
will be raised for every property if 1 or more properties changed events are
consumed. (more overhead, less coding)
i.e
PropertyChanged(object sender, PropertyChangedEventArgs e);

Method 2.
If I implement a PropertyNameChanged event then I have to have a delegate
and event for every property but it will only be raised if consumed on a 1
by 1 basis. (less overhead, more coding) (would not be hard to write an
addin to generate code for this).
i.e.
Property1Changed(object sender, EventArgs e)
or
Property1Changed()

If I use method 1 (which I am leaning towards at the moment) then I would be
inclined to add a string constant to the class for each property simply to
indicate the property name so I can use a switch in the consuming class to
determine which property changed and avoid typos when typing property names.

What have others done in this situation?

Cheers
JB

 

[John Baro]

Method 2.
If I implement a PropertyNameChanged event then I have to have a delegate
and event for every property but it will only be raised if consumed on a 1
by 1 basis. (less overhead, more coding) (would not be hard to write an
addin to generate code for this).
i.e.
Property1Changed(object sender, EventArgs e)
or
Property1Changed()

It would appear that this is the method commonly in use judging by the
framework and third party control libraries.
Where is Method 1 applicable then?

 

[Justin Rogers]

I just wrote an article that discusses meta-properties and property change
notification.

http://weblogs.asp.net/justin_rogers/archive/2004/04/26/120201.aspx

You'll find that I went with the concept of a storage container that fires a
single event
whenever any property changes, is removed, or added. Having a *Changed event
on a per property basis is a real PITA and does nothing more than increase the
size
of your control library.

Also note there are security issues with having events defined using the
standard
EventHandler. Various luring attacks can take advantage of the generic
signature
to run code using your privs rather than the privs of the code that attached the
handler. This is pretty sneaky, but it can happen.

 

[cody]

I need to implement an event to notify when a property has changed.

Method 1.
If I use a generic PropertyChanged event from System.ComponentModel then it
will be raised for every property if 1 or more properties changed events are
consumed. (more overhead, less coding)
i.e
PropertyChanged(object sender, PropertyChangedEventArgs e);

Method 2.
If I implement a PropertyNameChanged event then I have to have a delegate
and event for every property but it will only be raised if consumed on a 1
by 1 basis. (less overhead, more coding) (would not be hard to write an
addin to generate code for this).
i.e.
Property1Changed(object sender, EventArgs e)
or
Property1Changed()

If I use method 1 (which I am leaning towards at the moment) then I would be
inclined to add a string constant to the class for each property simply to
indicate the property name so I can use a switch in the consuming class to
determine which property changed and avoid typos when typing property names.

What have others done in this situation?

You can use MethodBase.GetCurrentMethod() to determine the name of the
property which fired the event.