696 INHERITANCE CASE STUDY:"UNDO"IN AN INTERACTIVE SYSTEM $21.I Multi-level undo and redo Offering an undo mechanism is better than not offering one,but it is not enough.Most systems that provide Undo limit themselves to one level:you can only cancel the effect of the last command.If you never make two mistakes in a row,this is enough.But if you ever go off in the wrong direction,and wish you could go back several steps,you are in trouble. (Anyone having used Microsoft Word,the Unix Vi editor or FrameMaker,in the releases available at the time this book was published,will know exactly what I mean. There is really no excuse for the restriction to one level of undoing.Once you have set up the undoing machinery,going from one-level to multi-level undo is a simple matter, as we will see in this chapter.And,please (this is a potential customer speaking)do not, like so many application authors,limit the number of commands that can be undone to a ridiculously small value;if you must limit it at all,let the user choose his own limit (through a "preferences"setting that will apply to all future sessions)and set default to at least 20.The overhead is small if you apply the techniques below,and is well justified. With multi-level undo,you will also need a Redo operation for users who get carried away and undo too much.With one-level undo no special Redo is required;the universally applied convention is that an Undo immediately following an Undo cancels it,so that Redo and Undo are the same operation.But this cannot work if you can go back more than one step.So we will have to treat Redo as a separate operation. Practical issues Although undo-redo can be retrofitted with reasonable effort into a well-written O-O system,it is best,if you plan to support this facility,to make it part of the design from the start-if only because the solution encourages a certain form ofsoftware architecture(the use of command classes)which,although beneficial in other respects,does not necessarily come to mind if you do not need undoing. To make the undo-redo mechanism practical you will have to deal with a few practical concerns. First you must include the facility in the user interface.For a start,we may just assume that the set of operations available to users is enriched with two new requests: Undo (obtained for example by typing control-U,although following the Macintosh convention control-Z seems to have become the standard on PC tools)and Redo (for example control-R).Undo cancels the effect of the last command not yet undone;Redo re-executes the last undone command not yet redone.You will have to define some convention for dealing with attempts to undo more than what has been done (or more than what is remembered),or to redo more than what has been undone:ignore the request,or bring up a warning message. This is only a first shot at user interface support for undo-redo.At the end of this chapter we will see that a nicer,more visual interface is possible.696 INHERITANCE CASE STUDY: “UNDO” IN AN INTERACTIVE SYSTEM §21.1 Multi-level undo and redo Offering an undo mechanism is better than not offering one, but it is not enough. Most systems that provide Undo limit themselves to one level: you can only cancel the effect of the last command. If you never make two mistakes in a row, this is enough. But if you ever go off in the wrong direction, and wish you could go back several steps, you are in trouble. (Anyone having used Microsoft Word, the Unix Vi editor or FrameMaker, in the releases available at the time this book was published, will know exactly what I mean.) There is really no excuse for the restriction to one level of undoing. Once you have set up the undoing machinery, going from one-level to multi-level undo is a simple matter, as we will see in this chapter. And, please (this is a potential customer speaking) do not, like so many application authors, limit the number of commands that can be undone to a ridiculously small value; if you must limit it at all, let the user choose his own limit (through a “preferences” setting that will apply to all future sessions) and set default to at least 20. The overhead is small if you apply the techniques below, and is well justified. With multi-level undo, you will also need a Redo operation for users who get carried away and undo too much. With one-level undo no special Redo is required; the universally applied convention is that an Undo immediately following an Undo cancels it, so that Redo and Undo are the same operation. But this cannot work if you can go back more than one step. So we will have to treat Redo as a separate operation. Practical issues Although undo-redo can be retrofitted with reasonable effort into a well-written O-O system, it is best, if you plan to support this facility, to make it part of the design from the start — if only because the solution encourages a certain form of software architecture (the use of command classes) which, although beneficial in other respects, does not necessarily come to mind if you do not need undoing. To make the undo-redo mechanism practical you will have to deal with a few practical concerns. First you must include the facility in the user interface. For a start, we may just assume that the set of operations available to users is enriched with two new requests: Undo (obtained for example by typing control-U, although following the Macintosh convention control-Z seems to have become the standard on PC tools) and Redo (for example control-R). Undo cancels the effect of the last command not yet undone; Redo re-executes the last undone command not yet redone. You will have to define some convention for dealing with attempts to undo more than what has been done (or more than what is remembered), or to redo more than what has been undone: ignore the request, or bring up a warning message. This is only a first shot at user interface support for undo-redo. At the end of this chapter we will see that a nicer, more visual interface is possible