Subverting the first responder chain
Subverting the first responder chain
- Subject: Subverting the first responder chain
- From: John Stiles <email@hidden>
- Date: Thu, 27 Mar 2008 17:52:18 -0700
I am implementing a custom NSView subclass (actually a simple subclass
of NSOpenGLView) that implements -keyDown: in order to respond to user
typing. Typically, this works great.
However, I have a few menu items which respond to atypical hotkeys (e.g.
one responds to "space", another to "option+X"). In this case, I've
found that the view gets a -keyDown: event, which it dutifully handles,
and the menu hotkey is never handled. I'd prefer it if the menu action
were triggered and no -keyDown: event were generated, and that's exactly
what happens with more typical menu hotkeys like command+letters. But my
view doesn't know what is in the menubar and so, without adding a lot of
ugly special-case code, from within the view's -keyDown: handler, it
would be difficult to know whether I need to send the event to the next
responder or handle the key myself.
Is there any elegant solution to this problem? The last thing I want to
do is reimplement hotkey handling on my own, but I can't think of any
workarounds to this issue that don't involve my view taking on a lot of
extra knowledge about what's in the menubar, or completely hacking the
responder chain in some ugly way. It seems that I can't forward on to
the next responder and then ask "did you handle it?"—if the responder
chain fails to handle the event, apparently it just calls
-noResponderFor: on the window and that is that—there's no return value
of "YES" or "NO" or anything like that.
Help...!
_______________________________________________
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