We are probably going to make the jump into the 2.0 world relatively soon (due mostly to the FastSerialization feature) and the last I remember, 2.0 got rid of the PropertyChanged events in favor of INotifyPropertyChanged. Our app makes extensive use of the PropertyChanged events, and it would be a makjor undertaking to replace all this logic with INotifyPropertyChanged...is there an option in 2.0 to use the old databinding events?

I'm afraid there is not.

They're not offered both because .NET 2.0 doesn't allow both: if INotifyPropertyChanged is implemented (which it is) then the ...Changed events aren't allowed and vice versa. INotifyPropertyChanged makes life a lot easier so that's the one which is used.

You bind a lot of code to these ...Changed events? As these events are more or less meant for databinding purposes (at least, thats the reason they're there in .NET )

Otis wrote:

They're not offered both because .NET 2.0 doesn't allow both: if INotifyPropertyChanged is implemented (which it is) then the ...Changed events aren't allowed and vice versa. INotifyPropertyChanged makes life a lot easier so that's the one which is used.

You bind a lot of code to these ...Changed events? As these events are more or less meant for databinding purposes (at least, thats the reason they're there in .NET )

We use these changed events to notify parts of the program that a value has changed, in order to make something happen. For example, if a boolean value "AllowEdit" changes, we want to make some other textbox enabled. It is iffy to rely on the state of the GUI control the property is bound to because the changed events of the controls sometimes fire before the parse has happened, so we can't read the parsed value yet.

I suppose we "misused" the PropertyChanged events but it seemed reasonable at the time to be able to rely on them.