-----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 protected]) 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]
