On Nov 22, 2013, at 12:55 AM, [email protected] wrote: > > Sent from my iPhone >> On 2013/11/22, at 0:19, Matthew LeRoy <[email protected]> wrote: >> >> Good morning, >> >> I've got a document-based application and I'm trying to figure out the >> proper way to implement keyboard shortcuts for shifting focus around to >> different parts of my document window (similar to Xcode's Navigate > Move >> Focus to Next Area menu item). I've only been programming in Cocoa (or on a >> Mac at all) for about a year, and am having trouble deciphering the >> documentation for processing key events and determining which method is >> correct for my situation (let alone implementing it). >> >> My designers are calling for three keyboard shortcuts (Command+Option+G/O/N) >> that move focus to three particular areas of the document window. However >> there are no corresponding menu items for these commands in the application >> menu, so assigning key equivalents to those menu items and having it "just >> work" isn't an option. Reading through the documentation a few times, I >> *think* these are the options for processing key events: >> >> - as a "key equivalent" by overriding performKeyEquivalent: somewhere >> - as a "keyboard interface control" event >> - as a "keyboard action", processed somewhere in a keyDown: override, >> through the use of a key bindings dictionary >> - as an "application specific" command or action (not using a key bindings >> dictionary) >> - as characters to insert as text >> >> I think two can be crossed off the list from the start. Inserting characters >> into text is obviously not what I'm after, and from what I can tell, despite >> the name sounding very appropriate to what I'm trying to accomplish, >> "keyboard interface control" events seem to only deal with shifting focus >> within the key-view loop using the Tab and Shift-Tab combinations. That >> leaves me with key equivalents, keyboard actions, and application specific >> processing. >> >> Overriding performKeyEquivalent: seemed like a good option -- just override >> it on the document window's NSWindow subclass, since these are really >> window-level operations I'm trying to implement -- but then I saw the note >> in the docs that "NSWindow subclasses are discouraged from overriding >> performKeyEquivalent:" (albeit without any explanation as to why). Still, I >> gave it a shot, and found that the NSEvent parameter was always nil, which >> is really quite useless. >> >> The recommended way to handle keyboard actions seems to be to call >> interpretKeyEvents: and let the key bindings dictionary system call the >> appropriate action method -- but then the documentation for Key Bindings >> says that defining custom key bindings at runtime is not supported. That >> seems to leave an application specific handling implementation as the only >> remaining option… but the documentation discourages that as well, so I have >> to believe there's a way to make this work using one of the other built-in >> handling systems; I feel like this shouldn't be as difficult or complicated >> as it seems. >> >> So, any help -- even just a nudge in the right direction -- would be much >> appreciated. Thanks! >> >> >> _______________________________________________ > The correct and easy approach to doing this is to add menu items that > correspond to these actions to an existing menu like View or add a menu and > put them there. > Connect each one to an IBAction method you create. > Assign each one the kb shortcut in interface builder. > > Then, you have stubbed out the action methods themselves and it's easy to add > buttons or other scenarios that call the same method later. > This does two wonderful very Cocoa things: > 1) Users can reassign keyboard shortcuts as they should be able to in to > System Preferences. > 2) You simplify your controller by having one place to call the change logic. > > As a bonus you set yourself up for easy AppleScript and Accessibility support > and automating a portion of QA work. > > Take a closer look at how other common apps do things. There are good > conventions for good reasons.
No snark intended, but you're preaching to the choir here, as are the others who have also suggested the same thing. I fully understand and completely agree with the benefits -- both for me and for the user -- of adding corresponding menu items for these actions, and that's exactly how I would do it if the decision were mine. Unfortunately it isn't, and I've been unable to convince those making the decision to change their minds. I'll try using a custom NSView at the top level of the window and override performKeyEquivalent: there and see what happens. Thanks all. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
