Re: Undo and NSDocument problem.
Re: Undo and NSDocument problem.
- Subject: Re: Undo and NSDocument problem.
- From: Bill Cheeseman <email@hidden>
- Date: Wed, 16 Jul 2003 06:41:16 -0400
on 03-07-15 10:31 PM, Gus Mueller at email@hidden wrote:
>
Is this a bad design decision on my part? Having multiple windows tied
>
to a single document? Should I rework the application so that each
>
window has a single document?
>
>
I've thought about giving each window it's own NSUndoManager, but I
>
haven't quite figured out where to set that yet- it looks like each
>
window just ends up talking to the document's undo manager.
The way you're doing it sounds right, in principle. Normally, a document
should have its one undo manager. The document's model objects (or the
document itself, if that's where you keep the data) would use that undo
manager, whenever the user changes any data, to register or record the
change on its undo stack. No matter how many windows you have into that
document, changes to the data that the user initiates in any window should
end up affecting the document's data and its undo manager.
It sounds as if you either have a memory management or logic error in your
code where it changes the data and registers or records the change with the
undo manager, or your routines for updating text fields upon Undo are doing
something wrong. Without the relevant code, it's impossible to see where you
might have gone wrong. (But before you send a lot of code to the list, work
on it some more, yourself!)
Typically, the window controller for the window where the text field appears
will have an action method connected to the text field, and the action
method will call your document's or model object's "set" accessor method for
whichever model object or document instance variable is reflected in the
text field. The set accessor will register or record the current state of
the data in the instance variable with the undo manager, then change the
data to correspond to the new value the user set in the text field. When the
user chooses Undo, the undo manager calls the set accessor again, with the
old value. Every successive undo/redo will call the accessor again, toggling
the value and notifying any observers (usually one or more window
controllers) to update the text field(s).
It is certainly possible to rework the typical pattern, for example, by
giving one or more model objects a separate undo manager. But it doesn't
sound like your design calls for that approach.
Are you using notifications to update the text fields after any set accessor
call, including an undo operation? You would typically post this
notification in your set accessor. Then only windows that are still in
existence would observe the notification and update their text fields. If
you're trying to force any text field to update by a direct message to it, I
suppose you could run into trouble if the window has been closed in the
meantime (especially if the window is set to release on close).
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.