Problems with n-level undo

Problems with n-level undo

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


rossl123 posted on Sunday, July 22, 2007

Hi

I am looking for help regarding the n-level undo feature. (CSLA C# V1.0)

I have a Winform panel that is quite complex, ie it contains both bound and unbound controls (like treeviews and radio buttons), has multiple levels of data collections, and offers the user both Save and Reset methods that are implemented using the n-level undo feature. The reset functionality, as I have implemented it, attempts a single level undo, but users are finding this confusing (I shouldn't have used the word Reset on the button for a start), because the Undo isn't consistent for all changes made on the screen. This is mainly due to the fact that unbound controls have to be rebuilt after their underlying data is reset, which causes them to lose their selected index values, which fires off a whole round of index changed events when they are reset,  that can affect other dependant controls. The effect is that sometimes a change will be unwound, sometimes two at once, and sometimes none. I am slowly coming to the conclusion that perhaps an Undo feature is not what I should have provided, but instead a complete roll back, all the way to level 0.

I did go through a stage a while back of implementing a reset based on re-reading the data for the panel from the database, but I quickly ran into problems with this when it came to keeping the BO's parent collection synchronised. Then I tried looping the call to undo the BO until the instance was no longer dirty (IsDirty checkbox unchecked), not realising that the binder wouldn't necessarily have had a chance to update this control at the time I was testing it (perhaps I should have tested the IsDirty property on the underlying instance!).

So now I am confused. Should I struggle on trying to provide a truly predictable Undo that steps all form control changes back one step at a time, regardless of whether they are bound controls or not, or should I implement a complete reset of the BO from the database and put some effort into trying to ensure that the BO's instance in the parent collection is correctly replaced and thus ignore the n-level undo functionality, or should I try to work on undoing all updates back to level 0 to achieve the same affect?

Any advice, references, or even kind words gratefully recieved.

Copyright (c) Marimer LLC