< Previous PageNext Page > Hide TOC

Using Undo in Applications

The Application Kit supplements the behavior of NSUndoManager in several ways. It offers default undo and redo behavior in text. It includes APIs for managing the action names that appear with “Undo” and “Redo” in an application’s menu. And it establishes a framework for the distribution and selection of NSUndoManagers in an application.

Contents:

Undo and the Responder Chain
NSTextView


Undo and the Responder Chain

As stated earlier, an application can have one or more clients: objects that register and perform undo operations in their local contexts. Each of these objects has its own NSUndoManager and the associated undo and redo stacks. One example of this scenario involves custom views, each a client of an NSUndoManager. For example, you could have a window with two custom views; each view can display text in changeable attributes (such as font, color, and size) and users can undo (or redo) each change to any attribute in either of the views. NSResponder and NSWindow define methods to help you control the context of undo operations within the view hierarchy.

NSResponder declares the undoManager method for most objects that inherit from it (namely, windows and views). When the first responder of an application receives an undo or redo message, NSResponder goes up the responder chain looking for a next responder that returns an NSUndoManager object from undoManager . Any returned NSUndoManager object is used for the undo or redo operation. If the undoManager message wends its way up the responder chain to the window, the NSWindow object queries its delegate with windowWillReturnUndoManager: to see if the delegate has an NSUndoManager. If the delegate does not implement this method, the NSWindow creates an NSUndoManager for the window and all its views.

Document-based applications often make their NSDocument objects the delegates of their windows and have them respond to the windowWillReturnUndoManager: message by returning the NSUndoManager used for the document. These applications can also make each NSWindowController the delegate of its window—the window controller implements windowWillReturnUndoManager: to get the NSUndoManager from its document and return it. Here are examples for Objective-C and Java:

return [[self document] undoManager]; // Objective-C
 
return this.document().undoManager(); // Java

NSTextView

NSTextViews provide undo and redo behavior by default. For your application to take advantage of this feature, however, it must send setAllowsUndo: with an argument of YES to the text view. If you want a text view to have its own NSUndoManager (and not the window’s), have the text view’s delegate implement undoManagerForTextView:, to return the NSUndoManager.

The default undo and redo behavior applies to text fields and text in cells as long as the field or cell is the first responder (that is, the focus of keyboard actions). Once the insertion point leaves the field or cell, prior operations cannot be undone.



< Previous PageNext Page > Hide TOC


© 2002 Apple Computer, Inc. All Rights Reserved. (Last updated: 2002-11-12)


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.