Jacqueline Landman Gay <[EMAIL PROTECTED]> wrote:
>Is there a way to determine if the user has pressed a key on the
>keyboard while a handler is running? I know I can test for commandKey,
>shiftKey, etc. but what I need to test for is the "+" and "-" keys. I
>suspect the answer is "no" but it never hurts to ask.
>
>--
>Jacqueline Landman Gay | [EMAIL PROTECTED]
>HyperActive Software | 612-724-1596
>Custom hypermedia solutions | http://www.hyperactivesw.com
Hello, Jacque.
How long to the handlers take to run? If it is not too long, the problem
ought to be solvable. Also, when a key is held down for more than a
moment, it sends repeated keyDown messsages, so your solution will have to
take this into account.
If your problem is like one I wanted to solve recently, maybe what I found
to work could be modified to work for you.
I wanted to modify the consequence of pressing a certain button by having
certain keys held down while pressing the button. What worked for me was
to have the following keyDown handler in the script for the button:
on keyDown X
put X into LetterBox
send clearOutBox to me in 2 seconds
end keyDown
The autoArm property of the button has to be true for it to send the
keyDown message when the key is depressed with the cursor on the button. X
returns the character of the key. I then put this character into
LetterBox, which is a global variable.
The mouseUp handler for the button then checks the variable LetterBox to
see if it contains one of the relevant letters. If so, it modifies its
response accordingly.
The variable LetterBox needs to be global so that the keyDown and mouseUp
handlers can communicate. Since the contents of LetterBox persists, when
the button is next depressed, say with no key down, there is the
possibility of an incorrect outcome. That is the reason for sending the
clearOutBox message after two seconds. The handler, which simply empties
LetterBox, is:
on clearOutBox
put empty into LetterBox
end clearOutBox
This solution worked well for me. The user needs to learn the right
timing, having the key depressed a fraction of a second prior to depressing
the button, but that ought to be something that can happen. The user might
hold the key down for awhile, thus sending repeated keyDown messages. My
solution takes this into account and isn't confounded by such a contingency.
If this sounds a little familiar, it is because I described this sketchily
in starting the thread "Answer dialog: Undocumented feature or risky
hack?". It was a secondary issue there, but Scott Raney picked up on it
and commented with some concern about this approach. He said:
>My first reaction would be yes: you probably should be using an option menu
>for this choice instead of opening a dialog. UI hacks like having people
>hold keys down to change the behavior are just bound to get you in trouble
>at some point, even if you do only plan to document them for the expert user
>(e.g., some non-expert user will undoubtedly run into it and file a bug report
>about this unexpected behavior). A group of radio buttons or a list box could
>also be used for this. And never open dialogs one after another for a common
>operation: make one dialog with all the settings for that operation in it
>instead.
Based upon this suggestion, I've modified my approach along the lines Scott
suggested. In spite of that, the earlier method worked, and depending on
what you need to do, there might be some ideas here that work for you.
John Kiltinen
Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
