Trapping KeyPress Messages

[dunbarx]

Fixed. Trashed the pref file, and all came back to normal. Should have done that first. Sorry for the noise.

But Bernd, is your observation valid, about the visible of the message box? It does not matter here whether it is visible or not.

Craig

[jmk_phd]

Thanks to all who have contributed thoughtful suggestions.

I must apologize to Craig and SparkOut for not having replied immediately that they’d identified correctly the fact that I’m dealing with two distinct problems: the respondent (1) holding down a response key long enough to generate multiple keydown messages, and (2) pressing the response key two or more times in rapid succession.

My thanks to them also for reminding me that – rather than trying to tweak a script that runs hundreds of lines – it’s best to build from scratch a simple stack in order to test the fundamental routine. (This reminded me also that our computer code is much smarter than us, inasmuch as it does what it’s told rather than what we intend it to do.)

Anyway, the first problem – an overly-long keydown press – was solved without much difficulty. However – despite having tried inserting suggested checks that monitor time – I’m still unable to block a second quick keypress when one item is displayed: If by chance you give the stack a try, note that a second quick keypress is registered wrongly as a response to the subsequent test item.

This seems such a simple issue that I’d thought there might be some way to clear queued keyUp messages from the message path. Apparently not. Tried sending overly quick keyUp messages to a hidden field, hoping that these would not go further up the message path, but no luck.

(As regards the program, I've got to be mindful not to insert too many wait delays: The actual test consists of 208 items and has been criticized over the years as taking an overly long time to complete.)

I don’t mean for anyone to spend precious time troubleshooting my sample code. Still, if out of curiousity you’d like to try out a basic version of the test and witness first-hand that the first problem (a long keyDown) was resolved, whereas the second (a quick double keyUp) has not – and possibly even take a stab at inserting a fix into the code that might resolve the second problem – here’s a link to download the test stack:

https://newpsyc.com/TryTest_2.livecode

The code is contained entirely in the script of the single card.

I will keep experimenting and report back. Thanks again for everyone’s suggestions.

jeff k

[jacque]

This seems such a simple issue that I’d thought there might be some way to clear queued keyUp messages from the message path.

FlushEvents() will clear the queue, but only up to the point where it's executed. If the user taps the key again afterwards they've started a new queue. So I think you'd still need to issue the command after a brief wait.

Code: Select all

wait 1 second
get flushEvents("keyUp") 

There's also "autoKey" which flushes key repeats.

[dunbarx]

Hi.

The nature of the "KeyWhatever" type of messages does make it tricky to keep pesky additional ones from firing.

I have to go to bed, but I have a fairly well working version using the "keysDown" function. That is entirely different, and I bet will work

Will play tomorrow

Craig

[richmond62]

-

[dunbarx]

OK, here is a stack that I think does most of what you want. I suspect the card script can be tightened. At least it gets rid of those annoyingly overEager "keyUp/keydown" messages. The "keysDown" function has come to my rescue several times in the past.

To exit, which still needs work, you must place the cursor in the "abort" button.

TryTest_2.livecode.zip

(1.83 KiB) Downloaded 78 times

Craig

[richmond62]

And Craig, how dost thon ken juist qhat yon Italian wants, as things are someqhat obscure?

[jmk_phd]

Jacque --

The flushEvents("keyUp") was exactly what I'd been hoping would be available. It wasn't mentioned in the LC manual, and although I'd searched the LC dictionary for "purge" and "clear", for some reason it never occurred to me to consider "flush".

Anyway, inserting flushEvents("keyUp") after one item response is evaluated but before the next item is displayed solved the problem of an unintended multiple keypress affecting that subsequent item.

Although my last fix did correct the other problem -- namely, a long keyDown affecting subsequent items -- I will experiment with either flushEvents("autoKey") or flushEvents("keyDown"), in case either of these is a more elegant solution than my fix.

Thanks much!!

jeff k

[dunbarx]

Richmond.

Gee, chan eil fhios agam.

or

Gee, ah d nae knw

Craig

[dunbarx]

Jeff.

I made my latest stack example originally with it flushing events. But it is not required since I got rid of all messages. Anyway, just goes to show there are several ways around most problems.

Let know, please, if that example stack solves your issues. I enjoy keeping LC honest and on a short leash, especially when its own gadgets get rambunctious.

Craig

[jmk_phd]

Craig --

The stack that you'd posted for download does indeed avoid the problems that I'd encountered with respect to key input -- which you and SparkOut had identified early on in this thread as distinct issues. So I hope the time you spent experimenting with a solution was considered worthwhile.

Although obviously your script was simply a demonstration of concept, I'm reluctant to implement the same strategy: Clearly it works, but differs so much from my existing code -- which relies solely on handling keyUp messages -- that I'm afraid it will only introduce confusion. My modified implementation of a "flag" was sufficient to avoid multiple keyDown messages, and Jacque's suggestion to employ flushEvents("keyUp") was what I'd needed to prevent quick multiple keypresses from affecting subsequent test items.

In case you're curious, the test displays geometrical images -- some of which are rather complex, in some cases employing color -- rather than text. This classic neuropsychological problem-solving test consists of seven distinct subtests, each of which is governed by a different rule as to what constitutes the correct response. So, for example, given the item "AbCD" the correct response might be "4" or "2" or "1" or "3" -- all depending upon the rule that governs that particular subtest. It's one of the most accurate tests of brain damage.

BTW, the use of raw key codes in your script introduces the need to check for both keyboard number keys and keypad number keys, which of course differ and would require some additional code to convert to an actual number. Just a bit of extra code that I'd prefer to avoid.

Thanks so much for your hard work and for the insights you've provided me when programming future projects.

jeff k

[jmk_phd]

Richmond --

I've probably not gotten this right, but perhaps you get the message:



Your replies have helped me on several occasions in the past, for which I thank you.

Respectfully,

jeff k

[dunbarx]

Jeff.

Did I mention there are many ways to do stuff?

I like mine better, since it sideSteps some LC behaviors that require a struggle.

And I also do not like to go back to square one after a certain amount of investment. But every time I have, it was much better. The simple lengths of our respective scripts suggest so.

Anyway, know that the untold hours I spend working on things like this allow me, thankfully, to avoid speaking to my family.

Craig

[jmk_phd]

Just a quick update. My original query was prompted by two keypress-related problems I’d encountered: Although the app worked fine when the user simply tapped on a key (1-4) to enter a response to a multiple-choice question, the input for subsequent questions got screwed up when the user either (a) held down the key (generating multiple keyDown messages), or (b) tapped the key repeatedly in quick succession (generating multiple keyUp messages).

After messing for weeks with various strategies involving keyUp, keyDown, flushEvents, and/or setting “flag” variables, I revisited the sample stack posted above by Craig on 5-26-2022, which instead relied solely upon the keysDown function.

As I understand it, the principle (in code) was essentially as follows:

Code: Select all

wait until the keysDown <> “”
put keysDown() into tResponse
wait until the keysDown = “”
doChecktResponse

Adapted into a simple “proof of concept” stack that more closely resembles the skeleton of my actual script, this appears to solve both problems “a” and “b” noted above, while simplifying the script by eliminating keyUp, keyDown, flushEvents, and the use of “flag” variables.

I’ve not yet done the major rewrite needed in order to implement this strategy in my app – which requires including all sorts of error checks along the way – but I’m more optimistic than I’ve been in weeks.

A few caveats, however: The keysDown function yields a list of *raw* keycodes, so some additional scripting is required. For example, pressing “1” on the keyboard yields raw keycode “49” whereas pressing “1” on the numerical keypad yields “65436”. So to know which *actual* number (1-4) was chosen requires checking both cases. Moreover, because for my test only numbers 1-4 are allowed, it’s necessary also to exclude all other raw keycodes. Additionally, because keysDown returns a list when more than one key is pressed, it’s necessary to confirm that this consists of a single item. As long as one takes these possibilities into account, it's not a serious problem.

Thanks again to everyone who contributed to this thread!

jeff k

[richmond62]

A really, really bad case of being late to the party:

Code: Select all

on keyUp XXX
   switch XXX
      case "1"
         put "1" into fld "feedback"
         break
      case "2"
         put "2" into fld "feedback"
         break
      case "3"
         put "3" into fld "feedback"
         break
      case "4"
         put "4" into fld "feedback"
         break
   end switch
end keyUp

Could, also, be titled "The Drunkard Returns."