Re: NSTextfields and keyboard equivalents - am I missing something?

FROM : John Stiles
DATE : Tue Apr 22 23:54:01 2008

Mattias Arrelid wrote:
> On Mon, Apr 21, 2008 at 7:05 PM, John Stiles <<email_removed>> wrote:
> 

>> In "The Path Of Key Events" in the URL you posted, the #1 item in the list
>> is "key equivalents."
>>  AppKit checks keyDown events to see if command is held; if it is, it tries
>> to match it against the menus before passing it through the responder chain.
>>   

>
> Is this really the case? The control actually gets the chance to
> respond to the event in the "performKeyEquivalent:" according to
> debugger - before_ the menu item gets the event. And after re-reading
> #1 again, I really can't see that holding down the command key should
> bypass the ordinary chain?
>
> "A key equivalent is a key or key combination (usually a key modified
> by the Command key) that is bound typically to some menu item or
> control object in the application. Pressing the key combination
> simulates the action of clicking the control or choosing the menu
> item.
> The application object handles key equivalents by going down the view
> hierarchy in the key window, sending each object a
> performKeyEquivalent: message until an object returns YES. If the
> message isn't handled by an object in the view hierarchy, NSApp then
> sends it to the menus in the menu bar. Some Cocoa classes, such as
> NSButton, NSMenu, NSMatrix, and NSSavePanel provide default
> implementations."
>
> Am I missing something here, or what do you base your claim on? :)
> 

In practice, I have found that if the command key is held, menus will
get the event before the view hierarchy gets a shot at it, but if
command is not held, the view hierarchy gets first crack at it. For
instance, if you have a custom view that has first-responder, it will
get a key-down for the space bar even if you have a menu item with its
key equivalent set to the space bar—but it will not get a key-down for
command-C, the Copy menu item will get that first.

I've got a radar open on this behavior because I think it's unintuitive
that some menu equivalents are treated differently than others. But in
Leopard (and I think Tiger), that's how it is.

> 

>>  I think your best bet is to dim your menu item or remove its key equivalent
>> when a text field gains first responder, and then restore it when the text
>> field loses first responder.
>>   

>
> I thought about that, but that really isn't a "clean" solution; if the
> user so wants, the menu item action should still be able to be
> performed by the user choosing the item in the menu - even if the text
> field has focus (and in this case, I'd say it would be reasonable if
> the menu item's target would get the action message).
>
> What do you think?
> 

Remove the key equivalent from the menu item when your text field has
focus, and restore it when the text field loses focus.

Or in the action method for command+arrow, see if a text field has
focus, and if so, send an appropriate message to the text field
(-moveToEndOfLine: perhaps) and then return immediately.

I don't think it is going to get much more beautiful than that,
unfortunately.
>>  Mattias Arrelid wrote:
>>
>>   

>>> I have a simple test application with a few custom menu items. Let's
>>> assume that _none_ of these items has a key equivalent of COMMAND +
>>> (right arrow) for now.
>>>
>>> When the first responder of the application is an NSTextField, and the
>>> user produces COMMAND + (right arrow), the insertion point is being
>>> placed right after the last character in the text field. This is true
>>> as long as the text field stays the first responder. As mentioned
>>> earler, I _don't_ have a menu item with such a key equivalent at this
>>> point.
>>>
>>> If I add a menu item that _has_ a key equivalent of COMMAND + (righ
>>> arrow), what happens is that this item's action is performed when I
>>> press the above key combo - even if the text field is the first
>>> responder. Is this supposed to happen? When reading the Cocoa
>>> Event-Handling documentation, I stumbled upon this:
>>>
>>>
>>>     

>> http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/chapter_2_section_3.html#//apple_ref/doc/uid/10000060i-CH3-SW10
>>   

>>> Inspired by that, I enabled some breakpoints in my project. From
>>> these, I can see that the text field doesn't seem to care about saying
>>> "yes, I do respond to COMMAND + (right arrow)" when its
>>> "performKeyEquivalent:" is called, which explains why the menu item
>>> gets the action eventually. Is this correct?
>>>
>>> To sum things up: I want the text field to respond to all "standard"
>>> key equivalents (move cursor to front, end, move word forward/backward
>>> etc.), even if I have a menu item with such a key equivalent. There
>>> are applications that behave like this, e.g. iTunes, and I do think
>>> that this is the correct behavior. Could anyone point me in the right
>>> direction here?
>>>
>>> Regards
>>> Mattias
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (<email_removed>)
>>>
>>> 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/<email_removed>
>>>
>>> This email sent to <email_removed>
>>>
>>>
>>>