Q: Wait for keyUp?
Stian Oksavik
Hi,
in one of my programs, I am using a custom dialog filter to handle
password input (a s.k. bullet filter.) Unfortunately, the filter also
needs to take care of certain tasks that I would normally have left to
Apple's standard filter - such as checking for command-period and enter,
highlighting the appropriate button when these are found, and handling the
outline around the default button.
I have most of this working, but one little detail is really bugging me:
When the user hits command-period (or command-q; the cancel button is
really a Quit button), I highlight the button. However, at this point I'd
*really* like to wait for the user to release the keys and then remove the
highlighting.
I tried a loop similar to the following:
blah bulletFilter(blah blah)
{
EventRecord myEvent;
/* other code here */
if (the user hit-command-period)
{ // highlight the button
SetEventMask (everyEvent); // shouldn't be necessary but I tried it anyway
myEvent.what = keyDown;
while (myEvent.what != keyUp)
GetOSEvent (keyUp, &myEvent);
ExitToShell();
}
}
Everything works fine until I get to the while loop, which keeps running
forever no matter how many times I release the keys. I would also like for
it to check specifically for the release of the keys that were depressed
originally (ie. command and period or command and q, or enter or return in
the case of the default "Continue" button). But right now it's hard enough
getting it to check for *anything*.
Any help most apprecciated; you'll get credit in the finished app (only
freeware, no big deal.)
Please send replies as e-mail in addition to posting.
Thanks,
-Stian
Christian E. Hopps
In article <stian-10129...@slip-d-3.ots.utexas.edu>,
st...@mail.utexas.edu (Stian Oksavik) wrote:
> When the user hits command-period (or command-q; the cancel button is
> really a Quit button), I highlight the button. However, at this point I'd
> *really* like to wait for the user to release the keys and then remove the
> highlighting.
I don't recall why I did it this way (perhaps there is a problem with
receiving keyUp events..) When one of my objects wishes to be notified of
key up events I tell my event dispatching object to track a key for the
object. When an event is dispatched and the event objects is supposed to be
tracking keys it checks the keyboard (with GetKeys) and thus can tell if
the key has been released. The object is notified when the key is no
longer down.
Chris.
Timothy C. Delaney
> blah bulletFilter(blah blah)
> {
> EventRecord myEvent;
> /* other code here */
> if (the user hit-command-period)
> { // highlight the button
> SetEventMask (everyEvent); // shouldn't be necessary but I tried it
anyway
> myEvent.what = keyDown;
> while (myEvent.what != keyUp)
> GetOSEvent (keyUp, &myEvent);
> ExitToShell();
> }
> }
You should need to do a SetEventMask() - keyUp events are not received by
your application by default.
Try setting the event mask to explicitly include *only* keyUp events -
SetEventMask(keyUpMask) (or whatever it is).
However, I don't think this is good interface design. Rather than waiting
for the user to release the keys, key shortcuts should take place
immediately. In this case, upon receiving a keyDown event and determining
it is one you want to deal with hilite the button for about 20 ticks,
unhilite it and do whatever the button is meant to.
--
<http://www.zip.com.au/~magao/standard_disclaimer.html>
_/_/_/_/
__| __| _/_| _/_/_/ _/_| _/_/_/
_/_| _/_| _/ _| _/ _/ _| _/ _/
-/ _|_/ _| _/_/_/_| _/ _/_/_/ _/_/_/_| _/ _/
_/ __/ _| _/ _| _/_/_/ _/ _| _/_/_/
Tim Delaney ma...@zip.com.au
Mac/Windows SW Engineer, Bold ma...@bold.com.au
Jos Laauwen
>I tried a loop similar to the following:
>
>blah bulletFilter(blah blah)
>{
> EventRecord myEvent;
> /* other code here */
> if (the user hit-command-period)
> { // highlight the button
> SetEventMask (everyEvent); // shouldn't be necessary but I tried it anyway
> myEvent.what = keyDown;
> while (myEvent.what != keyUp)
> GetOSEvent (keyUp, &myEvent);
> ExitToShell();
> }
>}
>
>Everything works fine until I get to the while loop, which keeps running
>forever no matter how many times I release the keys. I would also like for
>it to check specifically for the release of the keys that were depressed
>originally (ie. command and period or command and q, or enter or return in
>the case of the default "Continue" button). But right now it's hard enough
>getting it to check for *anything*.
>
Try the next loop:
while ( myEvent.what != keyUp )
GetOSEvent ( everyEvent, &myEvent );
I tested your loop, not in a filter, but in a simple wait () routine, and
indeed, you have to wait for ever or use opt-cmd-esc!
After I changed keyUp by everyEvent it worked fine.
> SetEventMask (everyEvent); // shouldn't be necessary but I tried it
It is necessary, because mostly the keyUp's are masked out.
And please, save the system state of the EventMask, so you can restore it
before you leave your application.
And please again, let me know if this helps.
Timothy C. Delaney
In article <magao-ya02348000...@news.zip.com.au>,
ma...@zip.com.au (Timothy C. Delaney) wrote:
> In article <stian-10129...@slip-d-3.ots.utexas.edu>,
> st...@mail.utexas.edu (Stian Oksavik) wrote:
>
> > blah bulletFilter(blah blah)
> > {
> > EventRecord myEvent;
> > /* other code here */
> > if (the user hit-command-period)
> > { // highlight the button
> > SetEventMask (everyEvent); // shouldn't be necessary but I tried it
> anyway
> > myEvent.what = keyDown;
> > while (myEvent.what != keyUp)
> > GetOSEvent (keyUp, &myEvent);
> > ExitToShell();
> > }
> > }
>
> You should need to do a SetEventMask() - keyUp events are not received by
> your application by default.
Bah - I think I've worked out what the actual problem is. You're calling
GetOSEvent(keyUp, &myEvent);
when you need to call it with the key up *mask*
GetOSEvent(keyUpMask, &myEvent);