Thanks Conrad (and all others). I tried to simplify my issue to get clearer answers, but It seems I need to disclose more of my design.
1. I thoroughly read (and tried) most everything around this subject, including Matt Ghallager's , Katie-Dev and "The Mental Blog" attempts on better NSViewController integration into responder-chain. 2. My app is quite complicated and modular. Modules are bit-like browser plug-ins. They are self-contained bundles, and are responsible for specific views within the application's view hierarchy. They are controlled by NSViewController subclass of our own. 3. Modules are responsible for user actions on the objects they display. Therefore, they should validate menu items, and perform IBActions for these object even when the view is not visible, or not in focus (i.e., not in the current responder chain). For this reason, I need to attach my controllers to the responder chain in different places. Sometimes right after their view, sometimes right after their window, and sometimes, right after the Application object ( to provide application-wide actions which should be available even when there are no visible windows). I have another problem ---- supporting FullScreen mode. When you use Cocoa's fullscreen API's what happens is that Appkit creates a new fullscreen window, tears your "fullScreen view" from its original window, and installs it into the fullscreen window. When you go out of fullscreen mode, it tears the view and installs it back where it was. So --- My controllers may need to move to new windows as well. That's quite complicated, and I managed to set up a decent implementation for all this --- except that I don't have the answer to the questions I sent... 1. Why Apple says "After the Delegate" when delegate isn't a responder, and is never in the responder chain. 2. Who (and how) is reconstructing the chain (if it all...) when user switches windows. How can I deduce from the documentation what is safe to do, and how to avoid my controllers being thrown out of the responder chain without my knowledge. Thanks again! On one hand, I need On Sep 13, 2011, at 6:48 PM, Conrad Shultz wrote: > -----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]
