there is lot of questions about this or similar issues in this forum, but I didn't found any answer on it. :-(
Lets start describing the situation. The target application is Windows Forms application.
I took as an example the ProjectTracker the one with methods (you probably already know) BindUI(), Save() and Cancel() which operate over BindingSourceHelper and it's BindingSourceNode objects.
I'm having currently issues when I call Cancel() in which you invoke BindingSourceNode.Cancel(myBO).
When my business object model is composed from one root without children objects in it, e.g it contains only simple properties, the Cancel works fine and it can undo any changes in it.
But when my business object has one child object, the problem arrise. When called Cancel, it throws exception "Edit level mismatch in UndoChanges".
After a quit long investigation I found that the problem is caused by calling BeginEdit and CancelEdit from two different interfaces. The first one is IEditableObject (from System.ComponentModel) and second one is ISupportUndo (from CSLA). The first one is called by databinding and the second one from my UI through BindingSourceNode object. This creates internal inconsistencies because databinging calls IEditableObject interface by his mind and is called several times. This behaviour of databinding is handled in IEditableObject implementation by using flag, to prevent from being called more then once. On the other hand ISupportUndo allowes to be called any number of times (which is supposed to be allowed).
So after that I tried to replace ISupportUndo with IEditableObject in Bind, Apple and Cancel methods of BindingSourceNode class. And as I supposed it worked.
What do you think about it?
I think it should be correct fix, because you should keep the same number of calls of BeginEdit on business object whether it is called from databinging through IEditableObejct or through ISupportUndo.
The other question arise, when you want to achieve more then one level of undo. You will not be able to call it through BindingSourceNode, but only through business object, which I think should be also OK.
Thank You very much for your soon answers
Copyright (c) Marimer LLC