Re: Implementing keyboard shortcuts for shifting focus
Re: Implementing keyboard shortcuts for shifting focus
- Subject: Re: Implementing keyboard shortcuts for shifting focus
- From: email@hidden
- Date: Fri, 22 Nov 2013 14:55:24 +0900
Sent from my iPhone
> On 2013/11/22, at 0:19, Matthew LeRoy <email@hidden> 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.
_______________________________________________
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