Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: (Novice) help with Undo function
Message-ID: <3870@internal.Apple.COM>
Date: 24 Aug 89 17:37:01 GMT
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 78
References:<22321@andante.UUCP> <30755@ucbvax.BERKELEY.EDU> <34168@apple.Apple.COM> <30803@ucbvax.BERKELEY.EDU> <4796@thor.acc.stolaf.edu>

In article <4796@thor.acc.stolaf.edu> sobiloff@thor.acc.stolaf.edu (Blake 
Sobiloff) writes:
> to write a program in Microsoft's QuickBASIC and I would like to 
impliment
> a simple Undo feature.  None of the sample code that comes with QB shows
> an Undo implimentation.  I thought maybe FracApp would show me, but Undo
> seems to be handled by MacApp (gee, if I only had MacApp...).  Soooo...

Traditionally, Undo is something people add as an afterthought.  It is 
largely application-specific, which is why most sample programs don't do 
Undo.

I'll divide the problem into the user and programmer view.

From the user's view, there are several things to do.

(1) You should insert the name of the operation into the Undo item (so it 
reads Undo Paste or Undo Style Change, etc.)  Also, if the user chooses 
Undo then you should change the menu item to read Redo Paste, etc.  This 
ensures that the user can look at the item and see what it is going to do.

(2) When undoing a command, you should restore the select to the state it 
was immediately before the command was done.  When redoing a command you 
should restore the selection to the state it had immediately after 
executing the original command.  It is also desirable to scroll some part 
of the new selection into view, so the user can see what happened.

(3) You should implement Undo for all commands that change the document.  
Some programs don't allow you to undo commands such as type style changes, 
either because those are hard to implement or because the user can simply 
chang ethe type style back to what she wants.  The problem is that this is 
inconsistent, and the user can't tell if a certain command is going to be 
undoable.

(4) When the user performs the next command, the previous one is no longer 
undoable.  (Except that some programs now support multi-level undo, in 
which this is not true.)  It is nice  if the user can undo a command even 
after saving a document, but that may be more difficult to implement.  
Also, if you support >1 document opened at once, you have to decide 
whether each document has its own undoable command.


On the implementation side, the obvious way to implement Undo is to save 
enough state to reverse the command and redo it if necessary.  This works 
for most commands, but the exact implementation is application-specific.  

In a text processor, any kind of typing command involves replacing one 
block of text with another block.  (Either block may be empty.)  In a 
bitmap editor, you replace one area with another.  When moving an object, 
you simply remember how far you moved it, and move it in the opposite 
direction.

There are commands, however, for which this implementation takes too much 
memory.  Consider changing the font in a text document.  You would have to 
remember all the old font changes.  Or consider changing the fill pattern 
for all objects in a drawing; you would have to remember all the original 
fill patterns.

The solution is to use a filtering approach in these cases.  When the user 
changes the font, you don't change your internal data structures.  Instead 
you remember the affected selection and the fact that he font has changed. 
 When it comes time to draw the text, you draw the affected text in the 
new font rather than the font recorded in the data structures.  

To undo this command, you simply "remove" the filter and draw the text in 
its "true" font.  When the command is no longer undoable, you make the 
change permanent by changing the data structures.  

In either implementation, you need to remember the current selection at 
the time the command is executed.  That's because the user can change the 
selection and still undo the previous command.  (Changing the selection is 
not considered a change to the document.)

Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1