Hi Dave,
I tend to use the mouse as an input device with a visible mouse cursor only if absolutely necessary, i.e. when a pointing or tracking task is involved. For all other purposes, we had custom response boxes built from ordinary USB keyboards sporting only five buttons, with one box for each hand. Buttons internally map to none-numpad keys 1-5 (right hand) and 6-10 (left hand). Subjects provide responses always with their dominant hand on the respective box. We can thereby warrant that the same finger is associated with the same response regardless of handedness.
The centering trial came to my mind, too, I was just adding such a thingie to my script when I read your posting. Cumbersome? Yes. Avoidable? No, sadly.
If anybody is interested in the details of my implementation, the script elements are set up as follows.
<values>
/ centeringtext=""
/ centertolerance=3px
/ screencenter.x=640px
/ screencenter.y=512px
</values>
<text TEXT_centering>
/ items = ("<%values.centeringtext%>")
/ position = (50,40)
</text>
<trial TRIAL_centering>
/ branch =
[if(sqrt(pow(trial.TRIAL_centering.responsex-values.screencenter.x,2) +
pow(trial.TRIAL_centering.responsey-values.screencenter.y,2)) >
values.centertolerance) TRIAL_centering]
/ validresponse = (lbuttonup)
/ responseinterrupt = trial
/ stimulusframes = [1 = sequence(TEXT_centering,PIC_centerspot)]
/ ontrialend = [values.centeringtext="Your mouse cursor is too far off the black dot. Please try again."]
</trial>
The expression "sqrt(...)" computes the euclidian distance of the click coordinate to the center of the screen. If the click commenced too far off the center, the trial alters the message issued by TEXT_centering and repeats itself. The values.centeringtext variable is reset to "Please click on the black dot at the center of the screen." by every trial that calls TRIAL_centering.
Bye, Malte