Preventing duplicate input

[jmk_phd]

I'm sure that I'm missing something totally obvious. Here's the situation: I have a 359-item questionnaire -- one card per item. Each card item requires unique code, depending upon several variables (English vs. Spanish, Adolescent vs. Adult, and -- for the Spanish-language variant -- whether gendered as either Male or Female.)

For any given item, there's a clickable button for each alternative response. In order to permit keyboard input (using number keys 1-4), I employ "keyDown thisKey" to click on the location of the corresponding button (e.g., to click button 1 if keyboard number 1 was pressed).

This all works fine unless the user either (a) clicks a button (mouseUp) in rapid succession, or (b) presses the corresponding number key (keyDown) in rapid succession. In either case, the second response is incorrectly registered as a reply to the next item.

I suppose that I might be able to set a stack custom property -- say cDidReply -- to true once the first reply is inputted, in order to prevent any additional mouseup or keyDown messages, then reset it to false upon moving to the next item.

Still, this seems rather kludgy (and requires editing all 359 item cards). Any suggestions will be appreciated.

Thanks. jeff k

[richmond62]

Possibly bonkers:

Code: Select all

on keyDown KD
switch KD
case "1"
if enableKey1 is "false" then
      pass keyDown
  else
  send "mouseDown" to btn "Key1"
      set enableKey1 to "false"
  end if
  break
  default
     pass rawKeyDown
  end switch
end keyDown

Sorry: just made this up "off the top of my head" as getting ready for work and no time to try it out.

I'll try to have a more serious poke around in about 2 hours time.

[richmond62]

Well: the above was largely rubbish.

But this seems to work:

Code: Select all

on keyDown KD
switch KD
case "1"
  send "mouseDown" to btn "Key1"
      exit to top
  break
  default
     pass keyDown
end switch
end keyDown

-

-

[dunbarx]

Hi.

Probably need to see your code. That you automatically migrate to another item before "locking" the first keypress should be rewritten, and the problem will go away.

Your idea of setting a flag (a custom property) to "lock" the current item is sound, but as I mentioned above, I bet we do not need to do so if we rethink how the interface acts in the first place.

Post a snippet of how you made this.

Craig

[jmburnod]

Hi,
Does a time limit would be useful to avoid rapid succession ?

Code: Select all

local sStartTime, sTimeLimit
on opencard
   put  the milliseconds into sStartTime
   put  500 into sTimeLimit
end opencard

on keyDown pKey
   if the milliseconds - sStartTime > sTimeLimit then
      send "mousedown" to btn "key1"
      put  the milliseconds into sStartTime
   end if
end keyDown

Best regards
Jean-Marc

[dunbarx]

Jeff.

Jean-Marc has offered a timing solution. We have discussed setting properties to prevent unwanted excursions. There are likely many other ways to do this as well.

But I bet this can be dealt with right at the start. How are you doing what you are doing?

Craig

[jmk_phd]

richmond62 --

Thanks so much for your replies, which helped to illustrate in the simplest manner the problem encountered.

I've modified the .livecode file you provided with two additional cards in order to simulate my situation. Using your model, a single button-click or single keyboard-press does work just as expected, recording a response and then moving to the next item. However, two rapid button clicks or keyboard presses for the first item reproduces the problem I've encountered: namely, that the same response is registered for both the first and second card, then advances to the third card. (I've inserted a short delay so that the faulty entry for the second item is visible before the test advances to the third item.)

Consequently, I need to insert somewhere in the code a line that will block a second button press or keyboard click until the initial response is recorded and saved to disk before advancing to the next card/item.

Hopefully the attached modified version of your .livecode script illustrates the problem.

jeff k

key repeat blocker mod.livecode.zip

(1.58 KiB) Downloaded 165 times

[[-hh]]

You could use flushEvents().
Also it would be more safe to use mouseUp and keyUp instead of mouseDown and keyDown (the system keyboard repeat is triggered by keydown).

TMHO it may be much clearer to move by a button or key (e.g. 6 or Enter) to next card, then the input can be corrected before that.
With that "nextCard" trigger you have also the right moment to save to disk.

[bn]

Hi Jeff,

You could use get FlushEvents() to cancel all mouse events that occur during processing.
Please look at the dictionary for the details.

Code: Select all

on mouseDown
   put "success 2" into fld "ff"
   wait one second
   get flushevents("all") -- flushes all system events, 
   go next card
end mouseDown

Kind regards
Bernd

[jmk_phd]

Craig and Jean-Marc --

Thanks for your replies. Only because the app already must record the response time for each item -- i.e., the time between presentation of a new card and the response -- I'm reluctant to introduce possible confusion (at my end) by introducing an additional variable that tracks time.

Craig's confirmation of my notion that using a custom property -- a flag triggered by the first input that prevents advancing to the next item until reversed once the current response is recorded -- seems at least plausible. This is yet to be tested.

Originally, the app was designed with a "Next" button to advance manually from one item to the next. This worked perfectly, because even multiple button-clicks and/or keypresses would affect only the current item. The bug was introduced when my client insisted instead that the program advance automatically to the next item immediately upon a (mouse or keyboard) response.

jeff k

[jmk_phd]

-- hh

Thanks much for your reply. I've indeed debated using keyUp or mouseUp vs. keyDown and mouseDown, but found not sufficient guidance in the online LC Dictionary to decide how best to handle this problem.

As mentioned previously -- although I agree with you and originally had a "Next" button -- my client insisted upon moving to the next card/item immediately upon entering a response (either via keyboard or mouse-click). The problem code is somewhere therein.

jeff k

[jmk_phd]

Berndt (and -hh) --

Thanks for suggesting flushEvents(), with which I was not familiar. I will explore this alternative.

jeff k

[bogs]

I've indeed debated using keyUp or mouseUp vs. keyDown and mouseDown, but found not sufficient guidance in the online LC Dictionary to decide how best to handle this problem.

I'm no authority, but, I suspect that just using mouseUp and keyUp would have solved your problem before it was created (provided that you don't have any double click handlers further down the line).
From the Dictionary (emphasis mine) -

Tip: If the user clicks several times in rapid succession (for example, if the user clicks an "Increase" button that increases a number by 1), some of the clicks may send a mouseDoubleUp message instead of mouseUp. If your script only handles the mouseUp message, these accidental double-click|double-clicks> will be **lost. One way to prevent this is to install a handler in an object that's further in the message path, to re-send double-click|double-clicks>:

** And this is exactly the behavior you were looking for.

When you use the mouse down instead of up, you can't be sure where the mouse was released. It may have been pressed 'down' over a button, but it could have been held down and dragged elsewhere before being released, if you see what I mean.

[richmond62]

Personally: having had about 2 hours awake in the night with this thing going round in circles
in my head: I'd go for customProps:

Code: Select all

on keyDown KD
switch KD
case "1"
  if the "DONE" of btn "Key1" > 2 then
      exit to top
      else
      send "mouseDown" to btn "Key1"
      set the "DONE" of btn "Key1" to 3
      exit to top
      end if
  break
  default
     pass keyDown
end switch
end keyDown

Obviously (!) you'd have to have an openCard script to reset the "DONE" of each of your buttons to 0.

[dunbarx]

Bogs and I are together on this. Lets see what you started with, that is causing all this anxiety. This sort of thing should not need emergency surgery, nor fancy patches.

Craig