Multiple undo and redo

[Richard Gaskin]

Jim Ault wrote:

> Couldn't you create a substack "undo" and set a series of custom properties
> to the mainStack as a binary+save this stack.  In the beginning of stack
> development, this would be small overhead and the undo series could be
> purged when not needed any more.
> 
> Added benefit is that the undo states would be persistent.  Just make a tool
> bar button that would be clicked (or a message box command, or other
> trigger)
> 
> Agreed that this is not the most elegant solution, but it might be better
> than continually saving versions.

Agreed.  What I'm looking for (and I suspect Jacque as well) is a way to 
store states for any objects.  Sometimes this may be stacks, sometimes 
it may be a card, sometimes just a group, and sometimes just the text in 
  a field.

Text editing is apparently tricky, given the broad variance of such 
implementation across programs.  I've tried to follow the strictest 
interpretation of HIG recommendations (anything between deletes is a 
single undoable operation), but I must admit I sometimes appreciate 
other more atomic models which use returns, selection changes, or even 
pauses as the dividing line for undoing typing.

The other tricky thing to keep in mind with Undo/Redo is the need to 
maintain separate queues for each open document window.  This adds 
another layer of complexity, but is necessary for most traditional apps 
which allow any number of documents to be open.

For each of those document windows I maintain three arrays:  one 
describing the action (delete, create, etc.), one containing the data 
(for restoring deletions, locations, etc.), and one for a selection 
record to restore the selection to its previous state.

I suppose I could pack all of the related data into a single storage 
element as XML or some other delimited format, but I try to save clock 
cycles where I can and array access is lightning fast.

Using properties may not be a bad idea, and the performance hit over 
globals would not likely be noticeable since it's used in one of the 
slowest computing contexts possible, response to a user action.

But I've not needed to restore Undo states between sessions, and in 
theory there are additional complications in that; there may well be a 
good reason so few apps from bigger publishers bother.  I can't say I've 
considered it deeply enough to have an opinion either way.

Regardless of whether persistent or not, there certainly is a lot of 
overhead involved in crafting a good universal Undo/Redo system.  While 
I'm content to muddle along toward a solid method that ultimately 
supports a History palette, the more time I spend on it the more I begin 
to see metapatterns to what needs to be done, and increasingly find 
myself with the feeling that if I had Mark Waddingham over here at the 
loft for a weekend with a couple computers and a really good scotch we 
could probably outline some engine-level support to make universal 
Undo/Redo simpler and far more efficient.

I have a dream....

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com