ChildChanged Enhancment (?)

Turntwo posted on Friday, July 24, 2009

I noticed that changing a Child object does not raise the PropertyChanged event for the Child property in the parent object, which I would have expected (or maybe just hoped) it would do.  When I went to implement this myself, I realized that the ChildChanged event doesn't actually provide any info as to which property on the parent the child belongs to, so there is really no way to handle this.  Is it possible to add this information?  It looks like the framework just hooks into the events when the child is registered, so it would be difficult to add this functionality without adding a whole new layer of event indirection.  But is sure would be cool, and improve databinding support for things like PropertyStatus.

What I'm trying to do is have the PropertyStatus (in WPF) display an error if the ChildObject is in error (the view displays a read-only version of the data, and a popup is used to edit the data of the child).  I have a validation rule for the ChildProperty that just returns IsValid, but I have to handle ChildChanged, check the ChildObject type, and then trigger the PropertyChanged event for the associated property - this works OK, except when there are 2 children of the same class, in which case extra work is done.  Maybe there is a better way to handle this? 

RockfordLhotka replied on Monday, July 27, 2009

Data binding expects PropertyChanged to be raised for the object where the property changed. I discovered (by doing as you suggest in my original implementation) that data binding gets very unhappy if you start raising PropertyChanged events on other objects.

By "very unhappy" I mean that focus gets lost/changed on other controls, the UI flickers and the user, by changing one field in a grid, can all of a sudden find themselves on a completely different row in the grid.

PropertyChanged is "owned" by data binding. CSLA raises that event according to what data binding expects - to do anything else tends to render apps useless.