I have a business list as a property of a parent object. I have a couple business rules that fire on changes to this list. All was fine in 3.6 they fired but now that I've moved to 4.0 changes to children object in these lists don't cause the rule(s) to fire.
Any idea where to start looking?
My rules are firing for my simple properties, just not child changes in my list property.
I've removed my AddNewCore implementation all togethor from the BusinessListBase implementation allowing the default one to fire.
How were you listening for events? Are you overridding OnChildChanged?
I'm not listening to events. Nor am overriding OnChildChanged.
I'm simply attaching a business rule to a businesslist managed property. Expecting the rule to fire if I change a property of a child in that list.
ChildChanged isn't firing when I change a property of a child object which explains why the business rule isn't firing.
I've confirmed I'm using SetProperty. Not sure what I'm missing but it is getting frustrating...
Are you using a managed backing field for the child object reference?
I'm not sure what you are missing either. I have specific unit tests that establish that ChildChanged is raised when a child object's property changes, so I'm pretty sure it works in general. There must be some quirk to your specific scenario that's causing an issue.
Try simplifying the scenario to replace the issue and see if you can identify the specific cause.
If I override the OnChildChanged in the parent, I can then force a BusinessRules.CheckRules(ChildListProperty). Both list and actual child object change events happen in OnChildChanged and I can easily catch only the actual child changes.
But if I don't override OnChildChanged in the parent and force a checkrules the business rules that have the ChildListProperty as the PrimaryProperty won't fire when a child of the ChildList is changed?
That is correct.
It is funny, this has never really come up quite this way - and here we have two threads (there was another one just a couple weeks ago) where someone expected rules to run based on ChildChanged.
And it is a good idea. As I said in the other thread, I'm not entirely convinced that this is the majority scenario - which is why I've never automated the behavior. But now I'm starting to rethink my position - to the point that I've added this to the wish list anyway.
Copyright (c) Marimer LLC