Page 1 of 4
Trapping KeyPress Messages
Posted: Tue May 24, 2022 1:47 am
by jmk_phd
I am apparently ignorant of something very fundamental as to how the keypress is handled in the message path. Everything works fine when the user responds as expected: When an item is presented on screen, pressing a single number key (1-4) in response is recorded as correct or incorrect, then the app waits for the next item to display before she/he presses a key to respond to that new item.
However, because this app is designed for use with neurologically-impaired persons, it is quite possible that some may either press the response key twice in rapid succession (in which case the same response is wrongly registered for the next item and advances to the subsequent item) or hold down the response key for some period of time (which registers the same response for several subsequent items and advances automatically through these.)
I’d thought that using keyUp would prevent at least the latter, and – to no avail – I’d even employed waits and a script local to flag “false” after an initial response had been made, so as to prevent subsequent responses to the same item being entered. I’ve tried also commenting out any “pass keyUp.”
I don’t want to trouble forum members with wading through my code, if – as I suspect – there is a very simple way to prevent more than the initial keypress from making its way into the message queue.
Thanks much!
jeff k
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 2:17 am
by dunbarx
Hi.
You were on the right track in setting a "flag", an old-fashioned programming term.
On a new card make two fields. Put this in the card script:
Code: Select all
on keyDown tKey
if the lockout of this cd = "true" then exit to top -- a "flag" line
set the lockout of this cd to "true" -- a another "flag" line
put tKey into fld 1
put random(999) into fld 2
end keyDown
on keyUp tKey -- a "flag" handler
set the lockout of this cd to "false"
end keyUp
Without the flag stuff, pressing, say, "3" will indeed put a 3 into fld 1. But it will send a million random numbers into fld 2 if the "3" key is held down. The flag prevents this, giving you a 3 in fld 1 and a single random number in fld 2, and it doesn't matter how long you linger on that keypress.
That random number line is a placeholder for any amount of other gadgetry that you want to run.
Craig
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 2:25 am
by dunbarx
You mentioned you tried script local variables. This is adapted from my first post, and works fine:
Code: Select all
local xx
on keyDown tKey
if xx = "true" then exit to top
put "true" into xx
put tKey into fld 1
put random(999) into fld 2
end keyDown
on keyUp tKey
put "false" into xx
end keyUp
What was yours like?
Craig
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 7:59 am
by SparkOut
In the keyUp handler you could also put
Code: Select all
send "unlockResponses" to me in 500 milliseconds
or suitable time interval to prevent quick successive presses from triggering extra inputs.
Then in the same script, have an additional handler "unlockResponses" which does the flag setting.
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 1:40 pm
by dunbarx
Sparkout.
The OP's real issue is that if you hold a key down for a second or two, the "keyDown" message fires over and over. In other words, "keyDown" does not mean "I pressed a key", but rather "A key is currently down", and that will fire continuously at the idleTicks rate.
So a lockout flag has to be set, however that is done, to thwart all successive messages if the key is not released.
Craig
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 2:24 pm
by dunbarx
Sparkout.
Rereading the original OP post, I do see that there are two issues, the one you addressed being the "double click" one.
Spot on.
@Jeff k.
You need both gadgets.
Craig
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 2:39 pm
by dunbarx
And when I say both gadgets, I mean that you need to use the following:
Code: Select all
on keyDown tKey
if the lockout of this cd = "true" then exit to top -- a "flag" line
set the lockout of this cd to "true" -- a another "flag" line
put tKey into fld 1
put random(999) into fld 2
end keyDown
on rawKeyUp
set the lockout of this cd to "false"
end rawKeyUp
Why? Because all of a sudden, in fooling around, using a "keyUp" handler as I originally posted no longer works. This even though I wrote it at home last night and remade it from scratch on a new stack in my office this morning, where it worked just fine until five minutes ago.
This is sitting here staring at me right now. Back and forth with commenting out one or the other, the rawKeyUp handler works fine, and the keyUp handler does not. It used to, but now does not. I shall repeat myself in just a moment, but maybe first I will quit LC and try again.
Craig
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 2:47 pm
by dunbarx
Nope.
"keyUp" no longer fires. Setting a breakpoint proves it. The message watcher shows "keyDown", "rawkeyDown" and "rawKeyUp" firing, but not "keyUp".
Suddenly deprecated, I guess. I hope this change does not break any of my legacy code.
Tried this in a new stack. Same issue. All of a sudden, I cannot get the "keyUp" message to fire when I press a key.
Craig
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 5:17 pm
by jmburnod
Hi,
You may define and use a time limit between each keyup
Something like that:
Code: Select all
local sTimeLimit, sCurrentTime
on opencard
put 300 into sTimeLimit
put the milliseconds into sCurrentTime
end opencard
on keyDown tKey
if the milliseconds >= (sCurrentTime + sTimeLimit) then
if the lockout of this cd = "true" then exit to top -- a "flag" line
set the lockout of this cd to "true" -- a another "flag" line
put tKey after fld 1
put random(999) into fld 2
end if
end keyDown
on rawKeyUp
set the lockout of this cd to "false"
put the milliseconds into sCurrentTime
end rawKeyUp
Best regards
Jean-Marc
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 5:35 pm
by jacque
I think I'd just check to see if the question has been answered yet and then wait a suitable time before showing the next one. That is, record the first response as the answer but leave the question displayed for a second or two. If another response comes in within the wait time, ignore it but reset the timer. When the timer runs out without any more responses, display the next question.
You don't necessarily need a flag, but you need to cross reference the question with any existing response.
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 5:53 pm
by bn
Hi Craig,
dunbarx wrote: ↑Tue May 24, 2022 2:47 pm
"keyUp" no longer fires. Setting a breakpoint proves it. The message watcher shows "keyDown", "rawkeyDown" and "rawKeyUp" firing, but not "keyUp".
Suddenly deprecated, I guess. I hope this change does not break any of my legacy code.
Tried this in a new stack. Same issue. All of a sudden, I cannot get the "keyUp" message to fire when I press a key.
Craig
I think the problem is that you do not pass the rawKeyUp message, if you do keyUp will fire
Kind regards
Bernd
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 8:01 pm
by dunbarx
Bernd.
I think the problem is that you do not pass the rawKeyUp message
I know, but thanks for the reply.
The issue is that
without a "rawKeyUp" handler, that is, before I ever needed one, all of a sudden, this morning, the "keyUp" message would not fire. It did last night and it did this morning, same code on two different machines.
It was only when I discovered I could not use "keyUp" anymore I substituted the "rawKeyUp" handler, and the gadget worked. But I am still not sure what is going on.
Craig
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 8:05 pm
by dunbarx
I am starting a new thread, I am unsure I know anything anymore.
Craig
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 9:56 pm
by FourthWorld
dunbarx wrote: ↑Tue May 24, 2022 8:05 pm
I am starting a new thread
Seems related. Why a separate thread? How will people know where to post replies?
Re: Trapping KeyPress Messages
Posted: Tue May 24, 2022 10:16 pm
by dunbarx
Richard.
This is all about "keyUp", not about the two issues the OP mentioned. I think it should be dealt with separately.
Craig