Re: Menu shortcuts without modifiers?
Re: Menu shortcuts without modifiers?
- Subject: Re: Menu shortcuts without modifiers?
- From: Uli Kusterer <email@hidden>
- Date: Mon, 21 Dec 2009 17:44:06 +0100
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 an urgent issue. 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 uploaded a short Cocoa test app with some Carbon and Cocoa windows and two menu items to http://dl.dropbox.com/u/34351/CarbonInCocoaShortcuts.zip. 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.
> Can you post the backtrace of the call to the action method of your menu item? It's possible it's being invoked from some place other than -[NSApplication handleKeyEquivalent:].
It is sent from somewhere else than handleKeyEquivalent:, but maybe that's due to changes in the meantime (10.6 has been released, after all):
#0 0x00005c47 in -[AppDelegate testShortcutsAction:] at AppDelegate.mm:118
#1 0x98c6df86 in -[NSApplication sendAction:to:from:]
#2 0x98c6de39 in -[NSMenuItem _corePerformAction]
#3 0x98c6db2a in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:]
#4 0x98c6da16 in -[NSMenu performActionForItemAtIndex:]
#5 0x98c6d9c9 in -[NSMenu _internalPerformActionForItemAtIndex:]
#6 0x98c6d873 in -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:]
#7 0x98c61f79 in NSSLMMenuEventHandler
#8 0x90923e29 in DispatchEventToHandlers
#9 0x909230f0 in SendEventToEventTargetInternal
#10 0x90945981 in SendEventToEventTarget
#11 0x90971e3b in SendHICommandEvent
#12 0x90996b20 in SendMenuCommandWithContextAndModifiers
#13 0x90996ad7 in SendMenuItemSelectedEvent
#14 0x90b22131 in _HIMenuSendItemSelectedEvent
#15 0x90ad15aa in HIMenuBar::HandleKeyboardEvent
#16 0x90924423 in HIObject::EventHook
#17 0x90923e29 in DispatchEventToHandlers
#18 0x909230f0 in SendEventToEventTargetInternal
#19 0x90922f4f in SendEventToEventTargetWithOptions
#20 0x909576ec in ToolboxEventDispatcherHandler
#21 0x9092427a in DispatchEventToHandlers
#22 0x909230f0 in SendEventToEventTargetInternal
#23 0x90945981 in SendEventToEventTarget
#24 0x98efdb7b in -[NSCarbonWindow sendEvent:]
#25 0x98c5db2f in -[NSApplication sendEvent:]
#26 0x98bf14ff in -[NSApplication run]
#27 0x98be9535 in NSApplicationMain
#28 0x000031af in main at main.m:14
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.
Cheers,
-- Uli Kusterer
"The witnesses of TeachText are everywhere..."
_______________________________________________
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