Re: Where's the NSWindowController in a default document-based app
Re: Where's the NSWindowController in a default document-based app
- Subject: Re: Where's the NSWindowController in a default document-based app
- From: Mike Ferris <email@hidden>
- Date: Sun, 20 Jun 2004 12:02:18 -0700
Yes, that is correct. But since NSDocument is made the owner of the
nib, it really does play the role of NSWindowController (handling the
GUI objects, having outlets, being the target for actions, etc.). The
code is significantly different when you have NSDocument-only app or
NSDocument with NSWindowController(s) app.
It was easier for me to grasp what is happening this way. Though
technically NSDocument internally allocates its NSWindowController,
you never see it and its existence does not affect your code (at least
it should not).
So in reality (heh!) there is a NSWindowController, but NSDocument
handles most of its duties, so for all practical views and purposes
NSDocument is NSWindowController in a simple app.
The intent was that when using NSDocument in its simple form
(overriding -windowNibName instead of -makeWindowControllers), the
NSWindowController that in fact gets created should be considered an
implementation detail...
Personally, I almost always start by changing to use
-makeWindowControllers and have explicit subclasses of
NSWindowController (like Sketch does). I find that as the app is
implemented, there almost always winds up being enough meat in the
controller layer to warrant splitting up back-end document handling
from front-end interface presentation, so it winds up being worth
while.
Also, just one minor nit with Jim's explanation (hi Jim!):
FYI, full responder chain when a simple textfield is first responder
within a document's window (default Xcode document based application):
NSTextView:0xe46bb0
_NSKeyboardFocusClipView:0x1a8120
NSTextField:0x1b01a0
NSView:0x1b00f0
NSWindow:0xe310e0
NSWindowController:0x1abee0
WindowDelegate:0xe36500
NSWindowController:0x1abee0
MyDocument:0x1ab850
NSApplication:0x79130
ApplicationDelegate:0x5efa0
NSDocumentController:0x1878d0
This is not the true responder chain (as defined by -nextResponder
return values). The true responder chain of the key window is:
NSTextView:0xe46bb0
_NSKeyboardFocusClipView:0x1a8120
NSTextField:0x1b01a0
NSView:0x1b00f0
NSWindow:0xe310e0
NSWindowController:0x1abee0
For event processing, this is who will get a shot at events. For
action method dispatch, however, Cocoa does some extra stuff. NSWindow
will check with its delegate for action forwarding. NSWindow will also
check with the document of the window. NSApplication is also given a
shot at action messages and, in turn, it offers them to its delegate
and to NSDocumentController.
So, for nil-targetted action methods, Jim's list is right on. But it
is not the true responder chain. (The -nextResponder of the NSWindow
is indeed the NSWindowController, but the NSWindowController's
-nextResponder is nil.
The extra stuff for action dispatch is largely implemented through
NSApplication's -targetForAction:to:from: and related methods.
Mike
_______________________________________________
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.