Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Taking keystrokes from PopUpMenuSelect



on Wed, 7 Jun 2006 13:12:59, "Greg Minton" <email@hidden> wrote:

> Event handlers on control target and the menu don't catch keystrokes.
> As far as I can tell, the spacebar sorts of keystroke events are put on
> the event, but the raw keydown is pulled off without getting dispatched.
> I assume keyboard accessibility routines somewhere are taking these
> events?

See the relevant message from eric:

http://lists.apple.com/archives/carbon-dev/2005/Feb/msg00931.html

>>>>>>>
For historical reasons (meaning, "that's the way I happened to implement it
at the time"), arrows and tab keys in menu keyboard navigation aren't routed
through the event dispatcher at all; the Menu Manager runs its own event
loop, and after getting an event back from ReceiveNextEvent, if the event is
a RawKeyDown event and the character is an arrow or tab, we just handle it
right away. If the event is some other character, and is not recognized as a
command key, then we send it through the event dispatcher so it can be
turned into a text input event, for which we have a handler on the event
dispatcher target.
>>>>>>>>

Makes me wonder, could the above Menu Manager event loop be modified
to do something like this:

loop () {
    ...
//    What it supposedly does now:
//    /*err =*/ ReceiveNextEvent(...., &event);
//    if (event is keyDown (arrows or space)) do something...
    
    // modification:
    /*err =*/ ReceiveNextEvent(...., &event);
    err = SendEventToEventTarget(event, GetEventDispatcherTarget());
    if (err == eventNotHandledErr) {
        if (event is keyDown (arrows or space)) do something...
    }
}

That way app would have a chance to intercept those events.

[Generally speaking, IMHO it is a design flaw to have a low level
API that picks events and doesn't dispatch them - it leads to
situations like the above, when it is impossible to intercept certain
events in certain situations.]

> I could hack around this if there was a way to block the menu from
> closing when it thinks it's done.

I am not sure if there is a way to do this.

> Spacebar and other "command" keystrokes don't get to a handler installed
> on the UserFocus event target either.
> 
> Really seems like they should, doesn't it?

IMHO, yes, ultimately all events should be "interceptable".

Mike


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden

This email sent to email@hidden



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.