Trapping KeyPress Messages

[dunbarx]

Richmond.

There were two issues discussed here while you were drinking. The other one was all about the user being prevented from making quick multiple keypresses.

Craig

[richmond62]

Just bung in a wait statement.

[dunbarx]

Just bung in a wait statement.

Yes, you could fit that in. Bernd did so early on in this thread. But that seems inelegant, to use delays to thwart unwanted behavior.

The real issue here is that since LC is event-driven, it sort of goes against its grain to create a barrier against events. This of course is absolutely required in real life, as in this case. So does one bury events, divert them, build a wall against them, wait til they get bored and go home, what?

Depends on the situation.

Craig

[richmond62]

Whatever you do, don't deal with them like Vladimir Putin.

To me the tendency for keys to carry on firing because I am bit heeeeaaaaavvvy handed seems a design fault in computers rather than in LiveCode.

[dunbarx]

Jeff's intended users have special issues, and that is why there needs to be a software solution to a hardware problem.

Craig

[dunbarx]

seems a design fault in computers rather than in LiveCode.

Would you build in a delay between possible successive identical keystrokes? That would annoy more people than any such "fix" would solve. Anyway, there already is that sort of property, the "key repeat" rate, at least on Mac. But even that only comes into play if one holds the key down for a while. And anyway there are certainly times when that is desired behavior.

Craig

[mwieder]

I'm coming very late to this party, so it's possible I haven't yet grasped all the nuances, but does this address the issue?

Code: Select all

local sLastkey

on keyDown pKey
   if sLastKey is empty then # initialize
      put pKey into sLastKey
      put pKey after me
   else
      if pKey is sLastKey then
         # do nothing
      else
         put pKey after me
      end if
   end if
end keyDown

on keyUp pKey
   put pKey into sLastKey
end keyUp

[richmond62]

Would you build in a delay between possible successive identical keystrokes?

Yessssssss, I would: after all there is a theory that typing should be as naturalistic as possible:
I have never known a second letter being mysteriously written just by my continuing to press
a pencil down on a page.

But my SWITCH script I posted earlier will NOT end up with end-users having 444444 or the like in the field.

While I realise the OP is trying to trap 1,2,3 or 4 as answers to a MCQ exercise the answer may lie in trapping
reponses in a field and dealing with them subsequently.

[richmond62]

-

-

[richmond62]

Code: Select all

on keyUp KP
   switch KP
      case "1"
         --- do nix
         break
      case "2"
         --- do nix
         break
      case "3"
         add 1 to fld "fREZ" of card "KARDend"
         break
      case "4"
         --- do nix
         break
   end switch
   go next card
end keyUp

[dunbarx]

Richmond.

Is something like this what you mean? I only used the first "case" statement for brevity:

Code: Select all

on keyDown XXX
   switch XXX
      case "1"
         add "1" to fld "feedback"
         wait 30
         break
   end switch
end keyDown

That does not do the job. "KeyDown" messages are queued. Try it. Click on the card rapidly and watch the field slowly build...

Craig

[jmk_phd]

Craig anticipated my reply to the point Richmond made when he wrote:

Jeff's intended users have special issues, and that is why there needs to be a software solution to a hardware problem.

The test is designed for persons suspected of neurological impairment. Whereas intact persons know to tap a response key once – in which case the keyUp strategy works fine – those with impaired motor skills are apt to hold down a key too long (generating a queue full of keyDown messages) and persons with impulse-control problems such as ADHD are apt to press more than once in quick succession (generating multiple keyUp messages).

Believe me, I’ve been working hard for over well a month to handle these two atypical situations. I’ve given Richmond’s posted MCQ.livecode stack a try, but when the response key is either held down too long or pressed again too quickly it does jump over items just as I experienced in my original design.

Neither wait commands nor flushEvents functions have proved to work. Inserting waits is problematic because it distorts the measure of response time, which is nearly as diagnostic as the number of errors.

Craig’s strategy of employing keysDown() is a pain in the butt on account of having to deal with raw keycodes, but so far it’s been the only strategy to work reliably.

You are welcome to give my “proof of concept” stack a try: It emulates very closely the design of the actual app – which administers two subtests and accepts only keyboard/keypad presses 1-4. (The test is literally a brain-teaser, so kudos if you earn a perfect zero-error score.)

Right now I’m struggling with how/where to insert a key combination that the test examiner can employ to terminate the test in case the client is clearly unable to complete the task. (Currently, the only way for the examiner to end the test is to respond to the remaining items – which for later subtests include 40 items.)

[dunbarx]

Craig’s strategy of employing keysDown() is a pain in the butt on account...

Jeff. First off, all my strategies are a pain in the butt. Ask my wife or kids.

But we are talking about mere handfuls of code to manage what I consider are trivial and straightforward issues, that is, the translation of assigned keyCodes. And once done, they are done. This sort of effort is just not onerous in my view, in fact a no-brainer, and this from someone with no brains at all.

Craig

[dunbarx]

So here is a slightly improved version, still exploiting the "keysDown" function. It now will not react at all if the user holds a key down, regardless how long. It still is not perfect if the user clicks away at a key for an extended period of time. I have some ideas on that, but it is late.

Anyway try this rather hastily put together stack. See if the repeated pressing of an answer key is tolerable. If not, more work is required, and I am thinking about rethinking.

KeyPressTest.livecode.zip

(1.38 KiB) Downloaded 133 times

Craig

[richmond62]

That does not do the job. "KeyDown" messages are queued.

I used keyUp.

As there are NO fields on the question cards keyDown does NOT . . .