Article View: comp.sys.mac
Article #15029Re: MacApp's undo ability.
From: lsr
Date: Fri, 13 Mar 1987 02:54
Date: Fri, 13 Mar 1987 02:54
50 lines
2964 bytes
2964 bytes
In article <1999@cit-vax.Caltech.Edu> wetter@tybalt.caltech.edu.UUCP (Pierce T. Wetter) writes:
>
> Another way to do this would be two have another method "Uncommit". This
>method would perform an undo for a command already commited. This also requires
In general, this would not work. The main reason for a command object
having a Commit method is that saving the state necessary to undo the
command is impractical.
Consider MacDraw. You select 1,000 objects and change their fills to
white. To remember the fill pattern of all the objects would require about
as much memory as the entire document.
Instead, you "make believe" the objects are white, but don't change the data
structures until the command is committed. Once it was committed, there
would be no way to uncommit it, for the same reason as above.
> A rational limit for a command stack would be from 2-4 (>4 might cause
>innumerable side effects between undos. if you undo a change to a deleted object
>do you undo the delete too?). Also needed would be another menu command. Undo #
>since undo toggles between undo and redo. What about if the user only wants
>to undo one of the commands on the stack? Should there be four commands
>undo "commandname" X 4? I'm not sure this is worth the trouble.
As long as the number of saved commands is >1, you have this problem. The
easiest thing to do is to undo commands in the reverse order in which they
were done. You could then add a separate Redo command that repeats the
commands in the original order.
Now this is not always what the user wants to do. S/he might have decided
that clearing that object 15 minutes ago was a mistake and wants to get it
back, but still wants to keep the rest of the changes made in the past 15
minutes.
That is a very tricky problem, both from a user interface point of view and
from a programming point of view. For more information about it, look at
the article "US&R: A New Framework for Redoing" by Jeffrey Vitter; IEEE
Software, October 1984. US&R stands for Undo, Skip, and Redo. This
mechanism gives users the maximum flexibility in undoing and reordering
commands.
--
Larry Rosenstein
Object Specialist
Apple Computer
AppleLink: Rosenstein1
UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET
Technical Details
Message-ID:
<532@apple.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!panda!genrad!decvax!decwrl!pyramid!voder!apple!lsrReferences:
<7932@watlion.UUCP> <1999@cit-vax.Caltech.Edu>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!panda!genrad!decvax!decwrl!pyramid!voder!apple!lsr From: lsr@apple.UUCP Newsgroups: comp.sys.mac Subject: Re: MacApp's undo ability. Message-ID: <532@apple.UUCP> Date: Thu, 12-Mar-87 21:54:20 EST Article-I.D.: apple.532 Posted: Thu Mar 12 21:54:20 1987 Date-Received: Sat, 14-Mar-87 02:53:12 EST References: <7932@watlion.UUCP> <1999@cit-vax.Caltech.Edu> Reply-To: lsr@apple.UUCP (Larry Rosenstein) Distribution: comp Organization: Advanced Technology Group, Apple Computer Lines: 50