Un-select and storing mid-trial variables

PennController for IBEX Forums Support Un-select and storing mid-trial variables

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #4113

    Hi Jeremy,

    Thanks for all of your help so far. New questions:
    (1) Is there a way to un-select an element (in this case, a scale element)?
    (2) Is there a way to collect data from a scale element which then may be changed, without disabling it upon first selection?
    We want to implement a replay button for our trials, and currently we have it implemented such that the trial plays and the scale can be selected, and then replay hides and re-shows the elements of the trial. But of course, the scale comes back already pre-selected. We’d like (1) to collect the initial scale selection, (if any,) and (2) to make it so that the final selection must be made after the replay is finished.

    My thoughts on (2) are currently in the realm of:
    – make a variable with how many selections have been made,
    – .settings.callback(if variable < 1, update firstRatingSelection var, then variable ++)
    so I’m working on implementing this now and we’ll see how that goes but please let me know if you have thoughts on why this is the wrong way to approach.

    But even though it seems like a simple thing to put in replayButton.settings.callback() to un-select whatever is selected on the scale, I don’t see a way to do it.


    Hi Leo,

    (1) It’s definitely an option that’s missing for the Scale element, all there is at the moment is select

    (2) You can log all the selections that happen on a scale element, see scale.settings.log

    In your case, since the unselect command is missing, I would probably just create a new Scale element on replay, e.g.:

      newText("contextText", "Look at the square below").print(),
      newCanvas("square", 200,200).settings.css("background","red").print(),
      newButton("ok", "OK").print().wait().remove(),
      newText("instructions", "How red is it?").print(),
      newScale("firstScale", 7).settings.log().print().wait(),
      // Removing everything still on screen
      // Wait 500ms before reprinting
      // Print a new scale
      newScale("secondScale", 7).settings.log().print().wait()

    Let me know if you have any questions



    Hi Jeremy,

    Thank you for the help!

    Just a note: .settings.log(“first”, “last”) gives two lines in the results file per item, which are otherwise identical, having the same name. And if only one selection is made, it only produces one line per item instead of duplicating. This is a pain for data analysis and I haven’t figured out a way to deal with it post-hoc yet, so instead my current plan is to update a variable to the selected value by testing.selected each element in the scale.

    (And a random side note: https://www.pcibex.net/wiki/button-wait/ the code here does not seem to produce the text in .settings.before() on the “try it!” page.)



    Hi Leo,

    Thanks for the feedback. What do you think should be a consistent behavior? Should there always be two lines in the results file when you pass both “first” and “last”? If so, should there be a value somewhere in the line reporting “first” / “last” / “first-last” (in case only one selection happens) / “NA” (in case no selection happens)?

    In your case, as I was suggesting earlier, I would advise using a different scale on replay if it’s an option: this way, the two lines in the results file will have different names (the code from my previous message will generate two lines: one named ‘firstScale’ and one named ‘secondScale’). It will also ensure you always have two lines (Choice will read NA if no selection ever happened on a logged scale).

    Oh and also, just a reminder: “first” means the very first time the participant clicks the scale. This means that if your participant clicks on the scale more than once before validating the first presentation of the scale, and then goes on to replaying everything and clicks again on the (now unselected) scale, passing “first” to log will not log the value selected on the scale when the participant validated the first presentation (instead, it will log the first value that was selected, before they changed their mind). One more reason to use two different Scale elements.

    Thanks for the note on the button.wait page, I fixed the code.

    Let me know if you have any questions,


    • This reply was modified 4 years, 10 months ago by Jeremy.

    Hi Jeremy,

    Should there always be two lines in the results file when you pass both “first” and “last”? If so, should there be a value somewhere in the line reporting “first” / “last” / “first-last” (in case only one selection happens) / “NA” (in case no selection happens)?

    That would be my preference by default, since it’s not very convenient to delineate things in R by which line they appear on (and doubly so if the number of lines isn’t consistent). I don’t know how your code works but it seems like “first”/”last” etc. would be a good candidate to go in the area that just says “choice” now, since the particular choice on each selection is one of the choices that they made, meaning that “choice” is now ambiguous. I’m not sure how that would work with “all”, though, since you wouldn’t want to put in 14 lines for every scale if they selected on one of them 14 times…but in that case it might be enough to differentiate them by number. Since we end up with our data in wide format, the consistently two-line version is good for me, but I don’t know what other people use.

    At first I thought I can’t really use the newScale strategy you suggested, since we want them to be able to replay the scene as many times as they want. But since we’re not collecting all of the selections, just two of them, would it be fine to just create a secondScale every time they press replay? Or would that cause errors with the name overwriting?

    (Another side note: I don’t know if this is a one-or-two-off thing or a more generalized thing, but https://www.pcibex.net/wiki/selector-test-index/ this page’s text also doesn’t appear in “try it!”, even when I add print() to it.)


Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.