On Mon, Apr 21, 2008 at 7:05 PM, John Stiles <[EMAIL PROTECTED]> 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 (Cocoa-dev@lists.apple.com) > > > > 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/jstiles%40blizzard.com > > > > This email sent to [EMAIL PROTECTED] > > > > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
