On Feb 19, 2005, at 10:57 AM, Richard Gaskin wrote:
Geoff Canyon wrote:I would store a list of transcript statements designed to undo/redo the things you are doing. So if you move a rectangle to 100,300 I would get the long id of the rectangle and do something like this:
put "set the loc of" && it && "to" && tNewLoc & cr after gRedoString
put "set the loc of" && it && "to" && the loc of it & cr before gUndoString
set the loc of it to tNewLoc
I did something like this for fields and found it to be remarkably fast and efficient. The really great aspect is that you can undo/redo an arbitrary number of steps with one command: do line 1 to 100 of gUndoString undoes 100 steps, etc.
That's prettyt much where I'm headed now, but there's one aspect that's still problematic: Rev's built-in undo for text editing operations is something I don't want to replicate. For a single-level Undo it's easy enough to put a flag in the undo string to tell it to use the built-in undo command rather than any custom routine. But how would one handle this for multi-level undo?
If you're going to do multi-level undo, I think you have no choice but to ignore Rev's built-in undo completely. They can't be stored as far as I know, so once something else has been done they're lost.
I have a stack that demonstrates multi-level undo in fields. It was a thought experiment and isn't complete:
-- it doesn't concern itself with _when_ to take an undo step.
-- it doesn't handle copy/paste and drag/drop efficiently. It should work correctly, but the transcript generated is inefficient. For drag/drop, the command should be nothing but chunks, since no text has changed, but it's not that smart.
I'll email it to you.
regards,
Geoff Canyon [EMAIL PROTECTED]
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
