From help file: Entities no longer expose FieldNameChanged events.

Isn't this going to break backwards compatibility with code hooking into the FieldNameChanged events of the Entity classes?

Yes, but it's not supported in .NET 2.0. .NET 2.0 now supports 1 single event. These change events are for databinding purposes mostly, and .NET 2.0 dropped that scheme completely.

If a lot of people want them back, I can generate them back into the code, though it's recommended to bite the bullet and make the change. I know it kind of sucks, but MS has a habit of changing fundamental stuff every once in a while, especially databinding, take this example and the changes in databinding in asp.net..

Otis wrote:

Yes, but it's not supported in .NET 2.0. .NET 2.0 now supports 1 single event. These change events are for databinding purposes mostly, and .NET 2.0 dropped that scheme completely.

If a lot of people want them back, I can generate them back into the code, though it's recommended to bite the bullet and make the change. I know it kind of sucks, but MS has a habit of changing fundamental stuff every once in a while, especially databinding, take this example and the changes in databinding in asp.net..

I can see how this new way is better for databinding, but what about for just normal object to object event communication? The handling object will need some kind of CASE statement now, right? I can't seem to find a good "best practices" for INotifyPropertyChanged and therefore we don't really use it much. Its use tended to lead to uglier code as the property changed events were not strongly typed anymore.

It's in one way uglier, I fully agree. On the other hand it's more maintainable from the event raising side, as there's one generic routine which raises events. The code is also more compact, no longer a lot of events, just one.

Like I said, I've to see how it pans out. If people want the original events back, I'll generate an override in the generated classes and raise the 'old' events from there.

Otis wrote:

It's in one way uglier, I fully agree. On the other hand it's more maintainable from the event raising side, as there's one generic routine which raises events. The code is also more compact, no longer a lot of events, just one.

Like I said, I've to see how it pans out. If people want the original events back, I'll generate an override in the generated classes and raise the 'old' events from there.

Can both events live side by side in a databinding situation? MSDN says no, but this seems strange...

I think they can't live side by side as that's what's MSDN docs say indeed. I don't know why either, it might be there is still some code left in the v2 controls which will bind to both if they're present, I've no idea.

Otis wrote:

I think they can't live side by side as that's what's MSDN docs say indeed. I don't know why either, it might be there is still some code left in the v2 controls which will bind to both if they're present, I've no idea.

Its just too bad you can't AddHandler and then specify a specific eventargs of PropertyChanged to narrow down the event...like (in VB):

AddHandler PropertyChanged("FirstName"), AddressOf(HandleFirstNameChanged")

this would make the INotifyPropertyChanged usage much cleaner from the event-handling side. I know this doesn't make much sense though, because obviously you can't specify an event by passing a string value...maybe if there was some way to do:

AddHandler PropertyChangedManager.GetPropertyChangedEvent(EmployeeEntity, "FirstName"), AddressOf(HandleFirstNameChanged)

where GetPropertyChangedEvent would create an event and raise it when EmployeeEntity.PropertyChanged event fires with "FirstName" eventargs.

I don't know. I just can't find any useful instructions on how to use this INotifyPropertyChanged, outside of databinding, anywhere on the web!

Rule of thumb: if it has something to do with microsoft and databinding... there's always something stupid involved...

I'm with you though, from a USER's perspective the event doesn't make much sense, as in: it's encouraging weak typing: you've to test with strings what's the property's name. That's a step away from the typed version of one event per property.

Although I've always found that scheme retarted as well, because if the code which raises the event knows which property, why make that code utterly complicated by having a lot of events, which all do the same thing?.. But I guess there's no real solution...

One way I've seen something interesting done (in another framework) is that each entity property is just an object itself that exposes a value and a changed event, amongst other things like an IsNull property and other things I can't remember. Don't ask me how this works with complex databinding, but it does seem to solve the Changed event problem in a pretty elegant way.

True, though it doesn't work in databinding at all... sadly enough. That setup also solves nullable problems on .NET 1.x, too bad databinding can't deal with it..