Hi All, the subject says it. I'd wish to do the following

<item SOMEITEM>
/ 1 = ...
/ 2 = ...
</item>

<counter SOMECOUNTER>
/ items = SOMEITEM
/ select = noreplace
</counter>

Is that possible? Or must I go the indirect route, such as

<item SOMEITEM>
/ 1 = ...
/ 2 = ...
</item>

<counter SOMECOUNTER>
/ items = (1, 2, ...)
/ select = noreplace
</counter>

and then later in the script

getitem(item.SOMEITEM, counter.SOMECOUNTER.selectedvalue);

Can you help? 

The <counter> element's /items attribute does not allow referencing an <item> element, so option #2 is the way to go.

Thanks! I had the vaguest of hope that you might come up with an undocumented neat trick... [8-|]

For that I'd need to know what exactly what you want to do (preferably via a short snippet of runable code). There might be a more elegant way to go about things, not so much a trick / undocumented quirk*.

* of which there actually aren't that many, IMO.

Oh no, the indirect solution is completely fine! I require the same text snippet in multiple places and for multiple purposes across the experiment. For example, the item "apple" might be used as a text stimulus or as part of a filename.

Adding to that, ever since you pointed me to Inquisit's scripting capabilities, I tend to extract all logic from the stimulus elements (like random drawing) and organize it into expressions.

Everything after the expressions section of the script then only serves as a mere "trial player" which displays the pregenerated stimulus sequence. This gives me nice flexibility when doing more complex combinatorical randomization. Plus, it condenses all logic in one place instead of scattering draws and selections all over the script.

So, everything is just perfect with using getitem(). I was just surprised by the "items" property of counters behaving differently from the "items" properties of most other elements.

Best wishes,
  Malte

Okay, great. Thanks for elaborating on your approach -- interesting!

You're welcome! I know that I'm probably abusing Inquisit's expressions beyond belief. My expressions almost never return a value, which is contrary to what Sean initially intended them to do. Instead, I use them as mere functions to separate presentation and logic within my scripts.

This is closest to the few principles of code design I picked up during my (very) humble programming work.

p.s.: well, of course expressions always return a value. They have to by design. Only my scripts seldom use it.