Trapping KeyPress Messages

[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

[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

[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

[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.

[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

[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

[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

[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

[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

[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.

[bn]

Hi Craig,

"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

[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

[dunbarx]

I am starting a new thread, I am unsure I know anything anymore.

Craig

[FourthWorld]

I am starting a new thread

Seems related. Why a separate thread? How will people know where to post replies?

[dunbarx]

Richard.

This is all about "keyUp", not about the two issues the OP mentioned. I think it should be dealt with separately.

Craig