Re: becomeFirstResponder and keyDown
Re: becomeFirstResponder and keyDown
- Subject: Re: becomeFirstResponder and keyDown
- From: Quincey Morris <email@hidden>
- Date: Wed, 21 Oct 2009 10:14:29 -0700
On Oct 21, 2009, at 09:17, gMail.com wrote:
I would like to detect whether the 'e' key is pressed every time I
click on
an NSView. If the view is already the firstResponder, I can quite
memorize
that key pressed when keyDown and reuse it when mouseDown. Then I
erase it
when keyUp.
But if the user presses the 'e' key when the firstResponder is on
another
view, then he clicks on my view, I cannot detect that the 'e' is still
pressed. I have been trying to detect the key already pressed
subclassing
becomeFirstResponder but I get nothing. Any idea?
In other words, you want to use the E key as a modifier key, like
shift, option, command or control.
There's no really good way to do this, because the problem isn't well-
defined. If you look at it from one end -- when a key down event
arrives -- you don't actually know whether there *is* an E key or
whether *any* key was pressed, because the input system is
complicated, especially when non-Roman writing systems are involved.
If you look at it from the other end -- when a particular hardware key
is pressed -- you're faced with the complexities of deciding which
hardware key to monitor and how to monitor it.
If you look at it from somewhere in the middle, you can mess around
with (virtual) key codes, keyboard layout resources, event taps or I
don't know what else, but the results may still be unreliable.
One basic approach to a good-enough solution is to subclass
NSApplication and override its sendEvent: method. In the override,
check for key down and up events, and update a global with the current
state of the "key", before calling the super implementation. Your
mouse down method in your custom view can then refer to this global
state.
However, you'll still have several problems to solve, such as:
-- What if shift-E or option-E is pressed? Simply ignoring modifiers
is not necessarily an adequate solution, depending on the input method.
-- How does the keyboard event get consumed? For example, if there's
no responder that handles key down events, you'll get a beep every
time you press the E key, which probably isn't what you want.
-- Not every event is dispatched via -[NSApplication sendEvent:]. Some
controls may remove and discard events from the event queue. Some
controls may handle events in a local modal event loop.
_______________________________________________
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