On Oct 19, 2013, at 8:46 AM, Uli Kusterer <witness.of.teacht...@gmx.net> wrote:
> > On 19 Oct 2013, at 14:27, Andy Lee <ag...@mac.com> wrote: >> On Oct 19, 2013, at 6:58 AM, Martin Hewitson <martin.hewit...@aei.mpg.de> >> wrote: >>> Main Window with tabs: >>> close (cmd-shift-w) >>> close tab (cmd-w) >>> >>> All other windows: >>> close (cmd-w) >>> close tab (inactive, no keyboard shortcut) >>> >>> This is pretty much the way things work in Xcode. >>> >>> So, my question is, is there a smart way to do this, or do I need to >>> implement -validateMenuItem: on every window in the app and set the >>> keyboard shortcuts there? >> >> Untested idea: implement windowDidBecomeKey: and windowDidResignKey: in the >> delegate of the window that has tabs and do the switching of shortcuts there. > > Would rather recommend against this. I don’t think there’s any guarantee > given what gets called first, validateMenuItem: or windowDidResignKey:. You > might be obliterating something already set by the incoming window. True. > I’d recommend adding a validateMenuItem: handler in the application delegate, > as long as you’re aware that this won’t be called for modal panels or windows > that have sheets on them, but since those generally don’t enable the “Close” > menu item, you should be fine. At least then you’re modifying the items. My first thought was that the app delegate might not get a validateMenuItem: message if something earlier in the responder chain handles those menu items. But you could change the actions of the menu items to something unique to make sure nothing else in the responder chain handles them. --Andy _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
