LiveCode Forums.

Here's a new version which might keep some people happy because it has:
in the card scripts.

I am unable to see any difference.

BIG OUCH . . .

I just made a stack with this in the cardScript:
and what happened is that on key release I get a loooong string of chars in my field.

It seems impossible to LOSE those keyDown signals . . .

Tried setting the idleRate to 65535: no joy.

However, my MCQ stack WORKS because there is nowhere for keyDown signals to go.

Richmond wrote:

my MCQ stack WORKS because there is nowhere for keyDown signals to go.

It was an assumption on my part that keyDown messages were the culprit, only because the result was pretty much the same as what happened with my own original attempts: When one holds down (rather than taps) the MCQ response key for a little while on the first test item, when the key is released the stack jumps to the last card and reports one answer correct, without ever allowing the user to view or respond to the second and third items.

You know and I know to only *tap* the response key, but some impaired persons either do not or cannot. That's why the possibility has to be taken into account.

jeff k

Craig wrote:

here is a slightly improved version...If not (tolerable), more work is required, and I am thinking about rethinking.

Please be aware: Once I figured out how to adapt to my own situation the keysDown() strategy you described earlier in this thread, it works *perfectly* in addressing both overly-long and repeated keypresses. So no need to refine it on my behalf.

In my case, the challenge was adapting my design to work with raw keycodes. Solved by using switch to handle each case:
(a) keysDown() = the correct *keyboard* response (e.g., 49 if the correct response was "1")
(b) keysDown() = the correct *keypad* response (e.g., 65436 if the correct response was "1")
(c) keysDown() is in "49,50,51,52,65436,65433,65435,65430" if a wrong yet allowable (1-4) key was pressed
(d) keysDown() is not in "49,50,51,52,65436,65433,65435,65430" to ignore any other keypress

And because I need also to convert the keysDown() back to the actual number (1-4) chosen: So that's all great! The only issue now is how to allow the clinician to intervene with some key-combination that will terminate the test if it becomes clear that the patient is too impaired or agitated to continue.

According to the LC Dictionary, keysDown() yields a comma-separated list if more than one key had been held down, but whenever I insert an answer line to see how it reports a key-combination pressed, the result is always still only one item -- which is of no help.

And no matter where I've tried to insert one of the more usual ways of identifying key-combinations into the framework of Craig's keysDown() strategy, nothing seems to work.

jeff k

Jeff.

Have not seen your main handler, but my favorite exit strategy is to use a key combination. Is there a place in the handler to: By "place" I mean somewhere, in either a loop or in the "looping" of a repetitively called handler.

Craig

Jeff.

I see you have worked through the horrors of keyCode translation. Nicely done, and I hope you had fun building it.

Craig

keysDown does NOT work when you press a key:
- -
And, Yes, that is a pain-in-the-bum.

This works:
- -
So, you could have a keyUp script to catch when the clinician presses and then releases some obscure key
(such as a function key?).

Of course this presupposes tht the patient is sitting there patiently with their fingers pressing multiple keys
instead of getting "all agitated" at the clinician's intervention.

The only issue now is how to allow the clinician to intervene with some key-combination that will terminate the test

I'd be inclined to use commandkeyDown or optionKeyDown along with an arbitrary keypress. That way you don't need to interrupt your other key-based handlers.

Richmond.

It looks like you are getting exactly what the "keysDown" function is supposed to give.

In the mouseUp handler, you can hold down a handful of keys as you click a button with that handler in it. You will get a list of keys. If you just click without pressing any keys, you will get empty. All correct

And with the "keyUp" handler (assuming yours works, since mine does not), same thing. So what "works", and what does not?

Craig

Craig and Jacque --

You're entirely right: The idea was to employ one of our usual methods of recognizing key combinations to interrupt a subtest in progress. The trick was to find where to insert this when using Craig's keysDown() strategy. I found a spot in the subtest loop such that when the test administrator (not the patient) responds to the currently displayed item, then immediately presses the key combination, I can invoke the necessary routine to clean up and terminate the test.

Richmond and Craig (and all others who contributed along the way) --

I'm very grateful that you took enough interest to explore the inner workings of key messages on my behalf. Although my attention is turned now to incorporating the new "proof of concept" code into my actual application scripts -- namely, stripping out the keyDowns, keyUps, flushEvents, and use of wait flags in favor of what I'd found necessary to implement the keysDown() strategy -- I've learned a lot from examining the various code examples that have been posted here.

I'll post a brief final update when the revision is complete and I've confirmed that the standalone works on both Windows and Mac.

jeff k