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
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
