It is critical to understand how windows forms data binding works here.
The bindingsource itself will call BeginEdit() on the current object in the list. And if you change currency to another object, it calls EndEdit() on the current object, then BeginEdit() on the new current object. If you cause a cancel operation (user presses ESC in a grid, or you call CancelEdit() on the bindingsource) then the bindingsource will call CancelEdit() on the object, and will immediately call BeginEdit() on the object.
When you unbind the list from the bindingsource, your code needs to get a reference to the current item (item with currency in the bindingsource), set the bindingsource's DataSource to null, then call CancelEdit() (or ApplyEdit()) on the was just current object by using the IEditableObject interface.
None of this gets you to form-level undo btw. It only affects whatever object has currency in the bindingsource.
I don’t know. I have unit tests that specifically test all
the various n-level undo operations, as it is a sensitive area of the
framework. So that is one area where (assuming the object is coded right) it
really should work very reliably.
And it is relatively difficult to do something wrong in the
object itself – unless you mark the field as NotUndoable the BeginEdit()
call should take a snapshot just fine.
Rocky
From: k2so
[mailto:cslanet@lhotka.net]
Sent: Friday, November 07, 2008 11:51 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Parent / Child Undo
Thanks, Rocky!
But I have further checked on the object itself, by just the following code in
the constructor
ChildObject _objectInFocus = root.ChildCollections[id];
_objectInFocus.Begin();
_objectInFocus.Name = "undo_this";
_objectInFocus.CancelEdit();
It is in fact, that
_objectInFocus.CancelEdit();
does not even cancel any changes without any bindings .
Seems like smth wrong with the object... i am investigating now...
Any idea why that might be the case; something I might have missed when
declaring the object???
Copyright (c) Marimer LLC