ChildChanged Event not firing in CSLA 4.3 when using SQL Server Session State

ChildChanged Event not firing in CSLA 4.3 when using SQL Server Session State

Old forum URL:

mtavares posted on Friday, November 09, 2012

I've run into an issue switching my Session type from InProc to SQL Server.  Basically, a validation rule on the parent is not being re-run when my child collection has been changed.  It seems that the ChildChanged event is no longer firing when I change something in the child collection.   Based on looking at past posts it sounds like it could be a deserialization issue where my events are not being re-hooked.  But according to Rocky's response in this post: As of Csla 3.5 the child events are re-hooked automatically.  I'm assuming they should still be automatically re-hooked upon deserialization in 4.3, but can anyone tell me if this is not the case?  And if not, what do I need to do to re-hook my events?




JonnyBee replied on Friday, November 09, 2012

My preference (as long as this is encapsulated) is to override OnChildChanged method and add the code there rather than hooking into the events with an event handler. 

mtavares replied on Friday, November 09, 2012

Ok, changing it to use the override worked, and luckily I will only need to change it in a handful of places. But, is this considered a bug?  Should CSLA 4.3 be automatically re-hooking the events upon deserialization?

JonnyBee replied on Saturday, November 10, 2012

I believe the situation is as follows;

CSLA will rehook the ChildChanged event handler for child collection but NOT rehook YOUR event handler that you set to listen for ChildChanged. So the child changed event is raised (as proof by the OnChildChanged method is called) but YOUR eventhandler code is not called because it is unknown after deserialization.

So - it is your responsibility to rehook your event hooks by overriding OnAddEventHooks and OnRemoveEventHooks to add/remove your own event hooks.

Which is why I prefer to override the On.... methods - as this also allows me to chose whether my own code runs before or after the event is raised (sometimes I want to make sure that my own code runs first ) as there is no guarantee for that in an event handler

mtavares replied on Saturday, November 10, 2012

That makes perfect sense.  Thanks Jonny for both the answer and the explanation.  I appreciate your help.

Copyright (c) Marimer LLC