Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: 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

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