Problem with EditLevel caused by IsAssignableFrom

Problem with EditLevel caused by IsAssignableFrom

Old forum URL:

FrancoisB posted on Wednesday, December 08, 2010

Hi everyone, we recently upgraded from CSLA 2.1.3 to 3.6.0... I know, that's a big step and honestly we haven't change anything in our classes to accomodate this migration since the application is running fine and no time is allocated to its maintenance.

Our problem is that the UndoException is raised in the call to BeginEdit(); in a child class. Tracing the code made me realise that the call to UndoableHandler.GetCachedFieldHandlers(currentType); gets a lot of handlers and that IsAssignableFrom returns true for a class that has nothing to do with the child being  modified. It's the call to CopyState for that handler that raises the exception, since they're not on the same EditLevel.

Can someone tell me how that handlers list is populated and why we encounter this problem?

If needed I could provide the use case, which is a bit complicated... but we need a fix soon so any help will be greatly appreciated.



RockfordLhotka replied on Wednesday, December 08, 2010

Edit level exceptions are almost always due to a bug in the UI code, where a child object is left at an elevated edit level (has an outstanding BeginEdit) and some code tries to do any apply/cancel at a higher level in the object graph.

The stricter checks were introduced in version 3.0, and are probably the single biggest upgrade challenge for most people moving from 2.x to 3.x (when using Windows Forms).

FrancoisB replied on Thursday, December 09, 2010

Thanks Rocky for your quick response. The thing is, we don't have any explicit calls to BeginEdit on the UI side. The only place where we use BeginEdit is when the user makes a action that modify certain properties of a child object. We do so to be able to undo those changes, which is triggered by another action. There's no other use of the undoable mechanism (i.e. user pressing Escape) since data is not presented in a editable way.

My question remains... what makes the CopyState use another list as a parent when IsAssignableFrom is called? Would calling BeginEdit at appropriate moments on my parent object make a difference? I understand the stricter checks may be necessary, but what's the best practice regarding the use of Begin/Apply/Cancel edits? I read about n-level implementation in your Expert C# 2005 Business Objects book... is there a more recent practice I should know of?

Thanks again for your help. In the meantime, I'll probably look for a workaround that implies making my own undo approach. Since my use case is just going back to the previous version of my child object (one level), it might be my best choice...


RockfordLhotka replied on Thursday, December 09, 2010

Are you using Windows Forms? If so, data binding invokes IEditableObject automatically, and there are specific steps you MUST TAKE in your UI code/design for this to work properly. There's an entire chapter covering how this works in the Using CSLA .NET 3.0 ebook (

FrancoisB replied on Thursday, December 09, 2010

We are indeed using Windows Forms. I guess it's time for us at work to go and order that book...we already have 2005 and 2008 versions of your book on business objects (I did'nt read the latter though). Hope I find answers to my problem in that chapter you say, but it will be a good read notheless.

Thanks again for your support and keep up your great work. It was an honor being answered by no other than CSLA's founder :)


Copyright (c) Marimer LLC