Re: NSTextfields and keyboard equivalents - am I missing something?
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/1060i-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]
Re: NSTextfields and keyboard equivalents - am I missing something?
Mattias Arrelid wrote: 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? :) 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/1060i-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:
Re: NSTextfields and keyboard equivalents - am I missing something?
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. 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. 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/1060i-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]
