Dear Rocky, dear all,
I'm facing some EditLevelMismatch in Silverlight 5 & CSLA 4.5.500
My scenario is to have a DynamicListBase "ChildList" with children: "Child "and a grand child: "Child" (the same type used for children).
I'm opening the details of a 'Child', then add a grand child (the Clone of itself), then commit the changes:
(Child as IEditableObject).BeginEdit(); -- Child.EditLevel = 1 which seems fine
Child.GrandChild = Child.CloneAsNew(); -- GrandChild.EditLevel = 0, due to UndoableBase.ResetChildEditLevel, as the bindingEdit is true:
-- if (bindingEdit && targetLevel > 0 && !(child is FieldManager.FieldDataManager))
(Child as IEditableObject).EndEdit(); -- UndoException in AcceptChanges(0), it seems that 1 is expected for the child.EditLevel
With CloneAsNew() being sensibely equal to:
var clone = this.Clone();
clone.ID = -1; --reset primary key
Am I doing something wrong? Is this an unsupported scenario?
I just reopened your very good "Expert VB 2008 Business Objects" N-Level Undo... but I can't get it right.
Any guidance will be welcome.
I'm renaming the thread, as looking for how to patch CSLA code gave me some clues.
It seems that the problem comes from the fact that, when the clone object is still with 'BindingEdit' set true.
I have modified my CloneAsNew() as follow and it seems to work:
clone.BindingEdit = false;
I'm still not sure if I'm using CSLA incorrectly? And will get further complications by using the Clone() API.
Any feedback would be welcome
Copyright (c) Marimer LLC