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 protected])
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]
