Re: NSTextfields and keyboard equivalents - am I missing something?
Re: NSTextfields and keyboard equivalents - am I missing something?
- Subject: Re: NSTextfields and keyboard equivalents - am I missing something?
- From: "Mattias Arrelid" <email@hidden>
- Date: Tue, 22 Apr 2008 23:28:14 +0200
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? :)
> 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?
> 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:
> >
> > 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:
This email sent to email@hidden