Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Mattias Arrelid wrote:
On Mon, Apr 21, 2008 at 7:05 PM, John Stiles <email@hidden> 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@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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

This email sent to email@hidden


_______________________________________________

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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

This email sent to email@hidden
References: 
 >NSTextfields and keyboard equivalents - am I missing something? (From: "Mattias Arrelid" <email@hidden>)
 >Re: NSTextfields and keyboard equivalents - am I missing something? (From: John Stiles <email@hidden>)
 >Re: NSTextfields and keyboard equivalents - am I missing something? (From: "Mattias Arrelid" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.