| Reference | Downloads | Github

ratingScale bug: early keypresses registered as "response key", not also as "accept key"

Trials in my script end with the subject making a rating, for which I am using a ratingscale component. I wish to have the response keys (1 through 5) also act as “Enter”, so that pressing one of these keys makes the component accept the response without the need for “Enter” to be pressed. I’ve therefore added these keys to the acceptKeys list, in the component’s customisation code.

There is, however, a bug in how the ratingscale component handles early responses. If a key is pressed very soon (<1s) after the component starts, the key is registered as a response but not also as a key that is meant to end the component. Only if that key (or another) is pressed again does the component take it as an “accept” key.

The same bug occurs if the key is pressed even earlier than the onset of the rating scale screen. To prevent the “bleeding”, @Daniel suggested this workaround, which works fine to prevent “very early” (i.e. before the ratingscale appears on the screen) responses, but does nothing to prevent the behaviour described above, which concerns “early” responses (i.e. keys pressed immediately after the onset of the rating scale on the screen).

I’ve created from scratch a very basic example (an MWE) of a script where this bug is reliably reproducible. It’s here, in case any of the developers with an interest in ratingScale (Jeremy?) has a chance to have a look. Until a fix is released, a suggestion for a hack/workaround to prevent this behaviour would be much appreciated.

You should use the singleClick option.

I did, but it didn’t help…

Just to clarify: the responses here are given using keys, not mouse clicks. The singleClick option should therefore be irrelevant, but after checking it anyway, the problem (bug?) remains. Is there anything else I can try?

The name singleClick is not so good, it DOES apply to keypresses as well. I think you also need to have no minimum time:


You’ll need the event.clearEvents() call if you don’t want keypresses made during the “get read” phase.

Many thanks Jeremy. The minTime=0 line solved my problem.