Re: Responder-Chain question.
Re: Responder-Chain question.
- Subject: Re: Responder-Chain question.
- From: Conrad Shultz <email@hidden>
- Date: Tue, 13 Sep 2011 08:48:22 -0700
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/13/11 5:01 AM, Motti Shneor wrote:
> Hello everyone.
>
> I need to insert some controllers I have into the responder chain,
> in such a place that their functionality (IBActions and menu
> validation) will be available regardless of specific view focus,
> etc.
>
> Event Programming guide says:
>
> "You should never send setNextResponder: to an NSView object. You
> can safely add responders to the top end of a window’s responder
> chain—the NSWindow object itself if it has no delegate or, if it
> has a delegate, after the delegate.
I remember reading this and being somewhat confused by it. For my
purposes I have chosen to set this guidance aside as needed.
In particular, I opted to insert NSViewController into the responder
chain in a manner akin to how UIViewController behaves on iOS,
allowing me to implement the "C" part of MVC much more cleanly.
Matt Gallagher has a nice blog post on the topic, the best solution
(unfortunately) being to create a custom NSView subclass and override
the responder chain methods:
http://cocoawithlove.com/2008/07/better-integration-for-nsviewcontroller.html
> However --- the window delegate isn't an NSResponder to start
> with, and is only being delegated responder methods from the window
> --- it is never in the responder chain per se. (same goes for the
> App delegate).
>
> I have two questions: 1. Is it a typo, and the doc really means
> "windowController" instead of "delegate" ?? this makes much more
> sense.
No. Presumably to minimize such a potential source of confusion,
Apple explicitly puts "(which need not inherit from NSResponder)"
after references to delegates.
I haven't messed with the responder chain surrounding the delegates,
but the impression I get (and perhaps what might be the only option
from an implementation perspective) is that the delegates are not part
of the responder chain in the sense that you can't call
- -setNextResponder: on them, but that their delegating objects
internally attempt to send them messages before calling [[self
nextResponder] ...]. If this is the case, then you can't inject a
responder between the object and its delegate without overriding
methods in the delegating object.
> 2. If I have two windows, and each of them has such a custom
> controller inserted into its responder chain after the
> windowController (or delegate?). What happens when I bring them to
> front in turn (user clicks on each). Somewhere Appkit re-wires the
> responder chain, and connects the window to the application ---
> won't my controller be dropped out of the responder chain then?
I'm actually not sure, though this would be easy enough to test. It's
possible that AppKit traverses the responder chain, breaks the
connection at the highest level possible, and reestablishes the links
at that level, but I don't know.
The reason I'm unsure is that I haven't had cause to do so - if you
want a custom controller for each window, what's wrong with using
their NSWindowControllers, which certainly are handled properly by
AppKit and which are designed for this purpose?
- --
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5ve0YACgkQaOlrz5+0JdVZYgCdFsfZ9AexbTQNJfghrBze8HG5
GQwAnRmzVSACRnSae19899N42qU5qt5e
=OzKV
-----END PGP SIGNATURE-----
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden