general undo methods?

[Dan Shafer]

In Smalltalk and probably in Java as well there was/is the notion of an 
undo/redo framework. The Command Pattern, for example, is designed for 
just this task. If we could design a framework, it should be possible 
for us to come up with a way for us to define user events in such a way 
that they "notify" the proper object(s) in the framework when they 
change.

It would be a fascinating exercise and result in a potentially highly 
useful product, I think. It would probably have to be limited to 
certain types or categories of changes, but it does seem to me it would 
be feasible with sufficiently high levels of scripting skills.

Dan

On Feb 18, 2005, at 9:26 PM, J. Landman Gay wrote:

> 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
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>