general undo methods?

[J. Landman Gay]

On 2/18/05 6:53 PM, Richard Gaskin wrote:

> I just spent the last two hours reading up on how undo is done in other 
> systems, and it seems that there is no magic panaea in any of them. Good 
> undo is simply a lot of work.
> 
> The general method is to atomize your code so that every action the user 
> can do generates undo code stored in a queue, which is then invoked when 
> Undo is selected.

I wrote an extended undo for two different apps, and in both cases I 
used the general method you describe. One stack was my Klondike game, 
and "undo" in that one wasn't too hard. Since the game already needed to 
track the location of every playing card in the deck, I stored a line of 
text describing the location of all the cards after every user move, and 
pushed the line onto a "done" list. When the user chose "undo", I popped 
the top line off the list and reset the playing cards to the positions 
it described. At the same time, I pushed the line onto a "redo" list. 
This allowed unlimited undo/redo. I just kept moving the descriptive 
line from one list to the other. This would be hard to do in a stack 
that didn't lend itself to a way of storing a list of user actions.

The other stack was a client project, and that was more difficult 
because the user actions were more varied. I used a similar method, but 
did not store everything the user did. They were allowed to undo only 
certain things that I could easily track. Other things just got lost. 
They complained a little bit, but not too much after I explained how 
much it would cost them to implement any more. Customers don't always 
understand how much work it is to implement "undo", since virtually all 
software has it. To them, it seems like it should be simple.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com