Multiple undo and redo
ambassador at fourthworld.com
Mon Feb 19 02:40:48 EST 2007
J. Landman Gay wrote:
> Ben Fisher wrote:
>> Create a new stack. Create two buttons.
>> Delete one of the buttons. Go Edit->Undo, and nothing happens. Imagine
>> if this button had all the scripts for your application. This is a
> I didn't follow your recipe exactly, but I had a stack already made and
> opened. I deleted a button, then chose "undo" from the Edit menu, and it
> came back.
> This has always been my experience, so there may be something else that
> is preventing it from working.
Most HI guidelines define an undoable action as one that affects data,
but operations which change selection do not affect the queue.
But Rev operates differently: If you move a button, then click anywhere
on the card or do anything else which changes the object selection,
executing an Undo command will not return the button to its pre-move
location. In fact, the mere click off of the object purges the Undo
queue altogether (okay, maybe "queue" isn't the right word for a
single-item Undo, but I'm optimistic about the future <g>).
And not only is the undo queue purged, but when it changes as a result
of a selection change the undoChanged message isn't sent as one would
That latter item is a bug, but given the limitations of the current undo
mechanisms in Rev I'm not sure it's worth fixing.
And with those limitations, the former issue of purging the Undo queue
at unexpected times may not be a significant error given the nearly
infinite range of things one might want to undo and how few are
supported in the engine.
What's really needed is a fresh start on Undo as a whole. At a minimum,
there needs to be a message sent when the mouse is pressed outside of a
control when the pointer tool is active. While that small detail would
solve a great many complexities with implementing Undo for layout, it's
such a small baby step with so much more needed for other types of tasks.
When I think of good Undo architectures, I tend to think of good
frameworks. That's why I asked Ben about his previous experience on the
subject. I've been able to make hefty strides toward a universal
multi-step Undo/Redo system only to the degree that I'm writing apps
from scratch (as opposed to porting existing code, which I used to do a
lot of in the early days), and to the degree that those apps can be
written with a consistent style within a consistent architecture; any
deviance from any one of those areas would make the application design
to broad for a single mechanism to be useful.
But sometimes constraints like that can be very valuable. Consider MFC,
.Net, or Apple's Cocoa. Each of those has solid support for generalized
Undo systems, but the ease of tapping that Undo support is relative to
the developer's conformance to a wide range of other data management
subsystems and structures.
There are countless ways to get similar benefits in Rev, but rather than
attempt something as complete -- and as formal and rigid -- as a whole
framework, I think there's a lot that can be done on a more atomic level
in support of such efforts.
For example, being able to save object states would be great, esp. if
those objects can be containers like cards and even stacks. Being able
to store a container into a variable and restore it from that variable
would make the rest of managing Undo queues much simpler.
There may be other specific feature requests that would be useful but
which aren't un BZ yet.
What would be needed to see multi-level Undo implementable with relative
ease in any Rev app?
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the Use-livecode