On Apr 23, 2008, at 1:01 AM, j o a r wrote:
Did you hook it up to be the delegate of the window? That's how it
ends up in the responder chain. In this way it would appear *before*
the app, which typically is what you want. If you want to add
something *after* the app, don't use a window controller, use an
application delegate.
I don't know which window to hook it to. From what I understand in the
docs, Cocoa manages the responder chain dynamically, generally ending
with the App, App's delegate, and the NSDocumentController. As the
user activates various windows, the responder chain changes to reflect
the currently-main document, but it's always topped by the app.
To be frank, I hadn't noticed that the document controller was last in
the chain. Had I designed it, the document controller would be last,
but just before the App. I suspect this is because there's no
mechanism for saying "this object is the 'top'", and then having that
object point to the NSApp.
My code currently inserts my controller between the app and whatever
the app is pointing to. (I don't know what happens if an app delegate
is installed after that.)
I really need for my controller to be created at launch, but not its
window. I don't know if that's happening yet. But even though its
window may never be shown, it still needs to be there to support other
app operations, and to respond to the import action.
On Apr 23, 2008, at 1:06 AM, Cathy Shive wrote:
Does your window know about the window controller and vice-versa?
It's not clear how you're setting this up from your post, but you
might need to tell the window about your window controller subclass:
Good question. I sort of assumed that, because they are wired together
in IB, that they know about each other. However, as mentioned above,
the window may never actually be shown, but the controller needs to be
there anyway.
[window setWindowController:windowController];
Or the other way around?
[windowController setWindow:window];
Or using brute force, the window controller can add itself to the
responder chain after the window like this:
[window setNextResponder:self];
If they know about each other, it shouldn't be necessary to
explicitly set the window's next responder, though.
Like I said, the window might not be showing, so I can't really depend
on that mechanism to put my controller in the chain.
I'm sure most people deal with this situation by having NSApp respond
to the import command, and forwarding that on to the appropriate
object. That seems like a bit of a kludge in an environment where
something like the responder chain exists.
I'm sure this is mostly moot (at least in this case); it's probably
sufficient for my controller to live after the App, it's just less
elegant.
Thanks,
--
Rick
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
