Edit level mismatch in CopyState

Edit level mismatch in CopyState

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


Joffies posted on Thursday, April 24, 2008

Hello all.

I have been tryin out CSLA for a new project and like it very much indeed, so much to offer for LOB applications which is major plus, especially the reduced amount of code for the UI developer! So far so good, but i suspect databinding might make it a tad bit unpleasant if not applied correctly. :)

I have run into one error that i just cannot seem to get around especially when saving child objects as a property of a parent object.

When trying to save my parent object (Businessbase) with the child objects(BusinessListbase) i get a error "Edit level mismatch in CopyState".

When saving a parent object that does not have any childobjects, then the the save is successfull

I am currently using cslavb-3.5.0-080403.

Thanks for your help!

bmmathe replied on Thursday, April 24, 2008

Are you using WinForms binding? You have to make sure to set the binding sources RaiseListChangeEvents to false.  Also in 3.5 Rocky uses a method called UnbindBindingSource that sets the datasource of the root's binding source to null and calls EndEdit() on the bindingsource before the save takes place.  Check out PTracker. 

I got around this issue but now I'm having the exact same error when saving a root object that has a grand children.  Parent > Child Collection > Child > Child Collection > Child.  When a grandchild is present the exception is thrown.

Joffies replied on Thursday, April 24, 2008

I am actually using the PTracker as a sample and do infact use the UnbindBindingSource helper method. The root object saves when using the helper method, but when saving a root object with a child collection it fails with the mismatch in copyState.

 

 

AzStan replied on Thursday, April 24, 2008

Here's an obscure thing to check:  If you have an error provider on your bound form, make sure it is properly hooked up to the business object.

I tore my hair out for a week trying to find this one - my winform base class had an error provider on it, but I was sloppy and didn't always hook it up.  For some reason, it interacted with the data binding and caused the edit level mismatch with the child objects.  I never figured out why, but the results were black and white.  Other data bound UI controls might have similar interactions.

Joffies replied on Friday, April 25, 2008

Very obscure thing indeed and i find it hard to believe that the lack of an error provider would cause the error as I do have an error provider on my windows form.

The issue seems to be after saving or undoing what I have changed and then rebinding the UI and setting the BeginEdit method on the root object.  I use the exact same approach as the PTracker sample for 3.5.

 

Private Sub BindUI()
   
   
_user.BeginEdit()   <<<<-------
   
Me.UserBindingSource.DataSource = _user

End Sub

 

Joffies replied on Monday, April 28, 2008

I am guessing it must be something that I am doing wrong as I am replicating whats been done in the PTraker application. Will investigate more closely and hopefully spot what I am doing wrong.

The Error provider next to the field updated does indicate "index 0 does not have a value"

Joffies replied on Monday, April 28, 2008

After a closer inspection it turns out i did not add a second bindingsource for my Roles property on my windows form. It all works now. :) A seperate bindingsource is needed for each property that represents child objects.

Phlar replied on Tuesday, June 09, 2009

I am in a similar situation and thought I would ask for some help.  We have a typical Client object with Child objects (Contacts, Contact, Addresses, Address).  Our main WinForm contains a split container.  Panel 1 has a TreeView which we populate it with Applicant Name (Root), "Address Summary" (Child Node of Applicant Name), Individual Address (Child Node of Address Summary), Contact Summary (Child Node of Applicant Name) and Individual Contact (Child Node of Contact Summary).

Panel 2 populates custom Controls (WinParts) based on which node is selected on the TreeView.  The WinForm contains the Bind(), ReBuid() routines for the Parent CSLA object.  The controls are created and passed in the respective object for modification.

When we modify the parent object Applicant it successfully saves and updates.  When we select a child object in the TreeView (i.e. a specific contact) and attempt to save we recieve "Edit Level Mismatch in CopyState" error in the call the BindUI() when it executes Applicant.BeginEdit().

We want to be able to modify any object (parent, child, grandchild) but only save the details when the user clicks on the Save Icon/Menu/Button.

Each custom control has Binding Source Controls but only in the WinForm do we call the BeginEdit.  I've traced the error to BusinessListBase.CopyState.  The EditLevel + 1 > parentEditLevel.  Any idea how the current EditLevel was assigned 1?

Any other design or alternative ideals?

RockfordLhotka replied on Wednesday, June 10, 2009

Data binding will elevate your edit levels (and decrease them too) following its own rules.

When using Windows Forms, it is critical that you understand how data binding interacts with your objects or you'll have a very rough time.

There's a thread from perhaps 2-3 years ago where several people on this forum worked very hard to isolate all the rules. I took that information, applied it to CSLA 3.0 and also wrote a chapter summarizing the findings in the Using CSLA .NET 3.0 ebook.

Miguel Castro subsequently took that information and created the CslaActionExtender control that you'll find in CSLA 3.6, and that control is discussed in the Expert 2008 Business Objects book.

Even CslaActionExtender isnt' a silver bullet - it doesn't automate every type of UI layout. But it does automate the more common UI layouts (single object, list of objects, master-detail, master-detail-detail and so forth).

Phlar replied on Wednesday, June 10, 2009

Thanks Rocky,

I'll have another look at the eBook (it's been some time since I've read that section).

We haven't (yet) upgraded to the latest version of CSLA as we are still utilizing 3.5 but I might have a quick gander at the CslaActionExtender and the details in your latest book.

 

Copyright (c) Marimer LLC