|
Group: Forum Members
Posts: 93,
Visits: 281
|
Hi all, the Inquisit help on the "currentvalue" and "nextvalue" properties suggests that they should produce the actual content of an <item> or <list> element's current or next-selected value, respectively. However, I just noticed that these properties work differently for <item> elements than for <list> elements. Specifically, for the latter, they work as expected, but for the former, they seem to be returning the index rather than the content. This is surprising behavior that leads to unintuitive results, although it can be worked around by using the item method to call the currentindex or nextindex property respectively. I was wondering whether this was intended behavior? If so, what am I missing in terms of rationale? If not, it's not an urgent issue given the workaround, but perhaps it could be addressed in future builds? Here's some code to reproduce the issue and make it clearer: <block test>
/ trials = [1-5 = test]
</block>
<list testlist>
/ items = ("hello","world","this","is","a","test")
/ selectionmode = sequence
</list>
<text testtext>
/ items = ("hello","world","this","is","a","test")
/ select = sequence
</text>
<text showtest>
/ items = ("currentitem: List - 'list.testlist.currentitem' produces error, Text - <%text.testtext.currentitem%>
currentvalue: List - <%list.testlist.currentvalue%>, Text - <%text.testtext.currentvalue%>,
nextvalue: List - <%list.testlist.nextvalue%>, Text - <%text.testtext.nextvalue%>
item(nextvalue): List - 'list.testlist.item(list.testlist.nextvalue)' produces error, Text - <%text.testtext.item(text.testtext.nextvalue)%>
item(nextindex): List - <%list.testlist.item(list.testlist.nextindex)%>, Text - <%text.testtext.item(text.testtext.nextindex)%>")
</text>
<trial test>
/ stimulustimes = [0 = showtest]
/ validresponse = (" ")
</trial>
An interesting side effect of this is that a list returns an empty value if its currentvalue is called before the nextvalue has been called for the first time, but an item (and therefore a stimulus) defaults to its first value. Might be useful for some esoteric programming applications (and to differentiate the two element types functionally), but also seems a tad inconsistent to me. Just something to consider, I suppose.
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+xHi all, the Inquisit help on the "currentvalue" and "nextvalue" properties suggests that they should produce the actual content of an <item> or <list> element's current or next-selected value, respectively. However, I just noticed that these properties work differently for <item> elements than for <list> elements. Specifically, for the latter, they work as expected, but for the former, they seem to be returning the index rather than the content. This is surprising behavior that leads to unintuitive results, although it can be worked around by using the item method to call the currentindex or nextindex property respectively. I was wondering whether this was intended behavior? If so, what am I missing in terms of rationale? If not, it's not an urgent issue given the workaround, but perhaps it could be addressed in future builds? Here's some code to reproduce the issue and make it clearer: <block test>
/ trials = [1-5 = test]
</block>
<list testlist>
/ items = ("hello","world","this","is","a","test")
/ selectionmode = sequence
</list>
<text testtext>
/ items = ("hello","world","this","is","a","test")
/ select = sequence
</text>
<text showtest>
/ items = ("currentitem: List - 'list.testlist.currentitem' produces error, Text - <%text.testtext.currentitem%>
currentvalue: List - <%list.testlist.currentvalue%>, Text - <%text.testtext.currentvalue%>,
nextvalue: List - <%list.testlist.nextvalue%>, Text - <%text.testtext.nextvalue%>
item(nextvalue): List - 'list.testlist.item(list.testlist.nextvalue)' produces error, Text - <%text.testtext.item(text.testtext.nextvalue)%>
item(nextindex): List - <%list.testlist.item(list.testlist.nextindex)%>, Text - <%text.testtext.item(text.testtext.nextindex)%>")
</text>
<trial test>
/ stimulustimes = [0 = showtest]
/ validresponse = (" ")
</trial>
An interesting side effect of this is that a list returns an empty value if its currentvalue is called before the nextvalue has been called for the first time, but an item (and therefore a stimulus) defaults to its first value. Might be useful for some esoteric programming applications (and to differentiate the two element types functionally), but also seems a tad inconsistent to me. Just something to consider, I suppose. Lists don't have a currentitem property, so yes, this will produce an error -- there is no such property. A list's nextvalue and currentvalue properties return the item value, not the index. nextindex and currentindex return the index, respectively. Acessing the nextvalue or nextindex property effects a selection on the list (within the set /selectionrate; if set to trial, you only get one value or index per trial, regardless of how often you access the property. If set to always, you get a new value / index every time). Currentvalue and currentindex return the currently selected value or index, without effecting any (new) selection. If no selection on the list has occurred yet, there is no curentvalue / currentindex. A stimulus by default returns the first item (or index); the reason is that if it returned nothing, things would crash in an ugly way, especially if external files are involved (imagine a <picture> or <sound> or <video> element trying to display a null value). You are correct that nextvalue for stimulus elements behaves inconsistently, returning an index instead of a value. Eliminating these differences and making things more consistent overall is definitely a goal for Inquisit 7.
|