Re: Menu shortcuts without modifiers?
Re: Menu shortcuts without modifiers?
- Subject: Re: Menu shortcuts without modifiers?
- From: Peter Ammon <email@hidden>
- Date: Mon, 21 Dec 2009 17:35:00 -0800
On Dec 21, 2009, at 7:29 AM, Uli Kusterer wrote:
> On 18.09.2009, at 23:07, Peter Ammon wrote:
>> For key events without modifiers, like hitting the spacebar, the first responder of the key window should get first crack via keyDown:. So I'm not sure why you're seeing the behavior you describe. I wrote a quick test with a focused text field in the key window and a main menu item with Space as its key equivalent, and the text field "won" for spacebar.
>
> Hi Peter,
>
> just got back to this issue after having to drop it for some urgent work. A short recap: It seems the "winning" works for the space bar in Cocoa windows, but not for the arrow keys. In a Carbon window, neither of these keys get passed to the edit field, the menu items get triggered immediately. I've attached a short Cocoa test app with some Carbon and Cocoa windows, and two menu items that exhibits the problem. Just type into any of the text fields and then try to use the space or arrow key. You will get an NSAlert whenever the menu items get the shortcut instead of the text field.
>
>
[...]
>
> As an alternative, do you know if there is a way to find out what item (Carbon or Cocoa, both) really has the focus right now? If I had an NSView*/NSWindow*/NSResponder* or an HIViewRef/HIWindowRef, that I know has the actual focus right now, I could probably remove the menu item shortcut dynamically depending on what is focused.
>
Cocoa windows have the peculiar behavior that key down events without the command, control, or function key mask get sent to the window first, and then the menu. Events with any of those flags set get sent to the main menu first. Pressing an arrow key generates an event with the function key mask set, but the spacebar does not set any of these mask bits, which explains the behavior you're seeing. Carbon windows (including NSCarbonWindow) send all events to the main menu first, which is why the behavior is different between Cocoa and Carbon windows.
I think your suggestion of dynamically adding or removing the key equivalent is sound. The best place to do this would be in either an implementation of menuNeedsUpdate: in the menu's delegate, or in validateMenuItem: in the target of the menu item.
To get Carbon's notion of the focus, you can do this:
HIViewRef focusedView = NULL;
HIViewGetFocus(GetUserFocusWindow(), &focusedView, NULL);
To get Cocoa's notion, you would write:
NSResponder *fr = [[NSApp keyWindow] firstResponder]
The question of "who really has the focus" is a little complicated, because it depends on who is dispatching events. If you have a Carbon window in a Cocoa app, HIViewGetFocus() will normally give you a NULL view if a Cocoa window is focused, so you might start by checking with Carbon, and then checking with Cocoa if the Carbon focus is not a text field.
Hope this helps,
-Peter
_______________________________________________
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