Re: Best practice for hidden keyboard shortcuts

FROM : Philip Dow
DATE : Fri Nov 02 18:38:53 2007

Ah, I failed to mention that the views upon which the key equivalents 
act are not necessarily in focus, so they won't receive the keyDown 
events.

-Phil

On Nov 2, 2007, at 9:49 AM, David Spooner wrote:

> Phil,
>
> I had written a class of view which implements arbitrary key 
> equivalents (with some exceptions, like cmd-tab) by overriding both -
> performKeyEquivalent: and -keyDown: -- I don't recall the specifics, 
> but I know that both methods are called in different circumstances...
>
> dave
>
>
> On 2-Nov-07, at 9:20 AM, Philip Dow wrote:
>

>> I'm looking to provide hidden keyboard shortcuts in my cocoa app. 
>> Actually this was already working in Tiger but the technique I was 
>> employing seems to no longer work in Leopard.
>>
>> In Tiger I was using a hidden popup button. Worked great, but no 
>> more. I've search the lists for possible solutions but have not 
>> come across a concrete answer. Recommendations include using 
>> Carbon's kMenuAttrHidden, Leopard's new hidden menu attribute, 
>> performKeyEquivalent: and overriding NSApp's sendEvent:
>>
>> I don't mind delving into Carbon, but to get a MenuRef for a NSMenu 
>> I am required to use an undocumented method. I'd like to avoid that 
>> if i can. Leopard's new hidden menu attribute looks promising, but 
>> hiding a menu removes the key equivalents for its menu items, 
>> defeating my purpose. performKeyEquivalent would be great, but 
>> documentation says you are limited to key equivalents that have no 
>> modifiers or the shift modifier only. I'd like to use control and 
>> option as well.
>>
>> This leaves me with overriding NSApp's sendEvent: . My current 
>> thinking is to check in that method for key events with the cmd 
>> modifier and ask the main window or window's delegate if it would 
>> like to handle a key equivalent. This is similar to the 
>> performKeyEquivalent: route except I can now use additional 
>> modifiers. If the window or delegate doesn't care to handle the 
>> event, I simply call super's sendEvent:
>>
>> Before I go through with this implementation I was just wondering 
>> if all of that sounds right or if there is a better way to do it.
>>
>> -Phil
>>

>



Journler Developer
<email_removed>