I have a strange scenario here. We have a Parent object with a BLB Child property as follows:
protected
internal static PropertyInfo<ChildrenBLB> ChildBLBProperty = RegisterProperty<ChildrenBLB>(c => c.ChildBLB, "Items", ChildrenBLB.NewChildrenBLB());
We have a scenario in which when we have no child objects (yet) when creating the parent, thus the default value (ChildrenBLB.NewChildrenBLB()) is execute.
In our UI code we when the user selects to add a child entry, we execute the following code:
ChildBB child = _parent.ChildBLB.AddNew()
This adds a new item to our data grid but does not fire the ChildChanged property. Modifying an existing item works and adding a new item where the BLB was not originally null (or the default setting in the RegisterProperty was not invoked) works as well.
Has anyone encountered this and have a solution?
Without digging to deep on your post, I noticed right away the following code:
internal static PropertyInfo<ChildrenBLB> ChildBLBProperty = RegisterProperty<ChildrenBLB>(c => c.ChildBLB, "Items", ChildrenBLB.NewChildrenBLB());
Focus on your default value of: ChildrenBLB.NewChildrenBLB()
This following is an answer Rocky gave me one time that is pretty good and may help you fix your issue:
------------------
Actually what you are doing is illegal. Remember that RegisterProperty() is a static method, so that default value you create will be used on every single object ever created - providing the same child instance to multiple parents.
It is not legal for an object to have multiple parent objects - this will cause all sorts of problems (wrong Parent value, messed up edit levels, etc).
Without digging to deep on your post, I noticed right away the following code:
internal static PropertyInfo<ChildrenBLB> ChildBLBProperty = RegisterProperty<ChildrenBLB>(c => c.ChildBLB, "Items", ChildrenBLB.NewChildrenBLB());
Focus on your default value of: ChildrenBLB.NewChildrenBLB()
This following is an answer Rocky gave me one time that is pretty good and may help you fix your issue:
------------------
Actually what you are doing is illegal. Remember that RegisterProperty() is a static method, so that default value you create will be used on every single object ever created - providing the same child instance to multiple parents.
It is not legal for an object to have multiple parent objects - this will cause all sorts of problems (wrong Parent value, messed up edit levels, etc).
Hi Rene,
This property is actually at the parent level which is the root object. Thus if the root object does not have any children, we want it to create the BLB object so that we can assign child object's to it. Is this still a problem?
After a little bit of rework and Rene's suggestion, we have moved the default creation of the BLB from the RegisterProperty. We have also moved our null check on the child result sets from the parent to the child BLB which creates the BLB in the object graph but with 0 elements.
That did the trick.
Hehe, you marked this as answered one millisecond before I was going to reply to your last post. Anyway, since I already have my reply written I am going to post it just for fun and perhaps clarify the issue 
---------------------------------------------------
Yes, it is still a problem.
What you will need to do is to either to call the "ChildrenBLB.NewChildrenBLB()" on you DataPortal_XYZ calls or on your property "get" method like:
public ChildrenBLB SomeChildrenBLBProp
{
get
{
if (m_Xyz == null)
m_Xyz = ChildrenBLB.NewChildrenBLB();
return m_Xyz;
}
}
The bottom line is that you should not have CSLA derived object used as default values on your RegisterProperty() calls because you will run in all kinds of issue. In practice, you will best of if you only used ValueType objec as defaut values.
There were talks about making the default value a delegate or throwing an error at runtime if anything other than a ValueType was used as the argument but I am not sure where we are on that.
Thanks for the additional details.
I had made the assumption that the default value would only be utilized if the property was null and that it was perfectly viable to call the respective child object static method to create the empty BLB.
Once I read your message I concluded my assumption was incorrect and made the necessary corrections.
Copyright (c) Marimer LLC