Preventing duplicate input
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Preventing duplicate input
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
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
-
- Livecode Opensource Backer
- Posts: 9385
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Preventing duplicate input
Possibly bonkers:
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.
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
I'll try to have a more serious poke around in about 2 hours time.
-
- Livecode Opensource Backer
- Posts: 9385
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Preventing duplicate input
Well: the above was largely rubbish.
But this seems to work:
-
-
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
- Attachments
-
- key repeat blocker.livecode.zip
- Here's the stack.
- (1.09 KiB) Downloaded 173 times
-
- VIP Livecode Opensource Backer
- Posts: 9660
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Preventing duplicate input
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
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
-
- VIP Livecode Opensource Backer
- Posts: 2718
- Joined: Sat Dec 22, 2007 5:35 pm
- Location: Genève
- Contact:
Re: Preventing duplicate input
Hi,
Does a time limit would be useful to avoid rapid succession ?
Best regards
Jean-Marc
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
Jean-Marc
https://alternatic.ch
-
- VIP Livecode Opensource Backer
- Posts: 9660
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Preventing duplicate input
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
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
Re: Preventing duplicate input
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
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
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: Preventing duplicate input
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.
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.
shiftLock happens
-
- VIP Livecode Opensource Backer
- Posts: 4000
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: Preventing duplicate input
Hi Jeff,
You could use get FlushEvents() to cancel all mouse events that occur during processing.
Please look at the dictionary for the details.
Kind regards
Bernd
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
Bernd
Re: Preventing duplicate input
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
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
Re: Preventing duplicate input
-- 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
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
Re: Preventing duplicate input
Berndt (and -hh) --
Thanks for suggesting flushEvents(), with which I was not familiar. I will explore this alternative.
jeff k
Thanks for suggesting flushEvents(), with which I was not familiar. I will explore this alternative.
jeff k
Re: Preventing duplicate input
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) -
** And this is exactly the behavior you were looking for.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>:
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.
-
- Livecode Opensource Backer
- Posts: 9385
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Preventing duplicate input
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:
Obviously (!) you'd have to have an openCard script to reset the "DONE" of each of your buttons to 0.
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
-
- VIP Livecode Opensource Backer
- Posts: 9660
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Preventing duplicate input
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
Craig