EditLevelMismatch after cloning a bound object

EditLevelMismatch after cloning a bound object

Old forum URL: forums.lhotka.net/forums/t/12667.aspx

g.beraudo@castsoftware.com posted on Monday, June 16, 2014

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))

      --     targetLevel--;

(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



return clone;


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.



g.beraudo@castsoftware.com replied on Tuesday, June 17, 2014

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