Does anyone have a workaround or solution to fix this issue?
I have a repeat group linked to a select_multiple question (ITEMS). Within the repeat, I need to capture the PRICE for each selected item. However, during data collection, enumerators occasionally need to add new items to the previously selected choices. The issue is that when new items are added, the previously entered prices shift, causing misalignment in the data.
Please refer to the attached screenshots for further illustration.
Dear @hm11 ,
have an idea to maintain the same value in a repeated group. First, I set the repeat group count to match the number of options in a multiple-choice question. Then, I created a trigger question using the formula selected(${items}, position(..)). After that, I applied this trigger for skip logic on the price variable.
In the KoBoToolbox preview, everything works as expected. However, I encountered a deployment error due to the selected(${},'') format.
How can I resolve this error when using selected(${q1},${q2}), where ${q2} is another question instead of a fixed value? Please check the screenshot and the error message for details.
Please be aware contains() is dangerous to use with multi-selects. This is because contains() simply does a purely substring match, whereas selected() actually checks for entire words (in the space-delimited array of selected choice names…)
So, for example, if you have a multi-select with say the animals - elephant, cow, anteater, cat, caterpillar, … - then a
contains(${animals}, 'cat')
will also match if you just selected caterpillar !
contains() will only work reliably for multi-selects if you can guarantee no choice name string will ever inadvertently be a substring of another.
You can actually do this already (!). To prove it, deploy this form which references another question - ${match} - in the selected() function as the target value instead of a literal.
I suspect the error that you are hitting is because pyxform (the XLSForm-to-XML translator) is being overly pedantic, and in your actual form you are in fact using the rather obscure position(..) function as the target value expression [so not in fact another question!]
However, instead of putting position(..) directly in your selected() expression, if you instead add another calculation to store the current repeat iteration number, and then reference this instead; eg
type
name
calculation
calculate
pos
position(..)
calculate
price_triger
if(selected(${items},${pos}),'1','0')
then you might be able to get around this.
FWIW, I’ve found position(..) to be a little ‘finicky’ at times when using it in repeat loops, so I often grab it with an explicit calculation like this, and then use the result in other calculations.
Dear @Xiphware,
I have tried the method you suggested:
type name calculation
calculate pos position(..)
calculate price_trigger if(selected(${items}, ${pos}), '1', '0')
Instead of using position(..) directly in the selected() function, but the same error still occurs.
Additionally, I have tested selected(${isParent}, ${match}) using another question in the selected() function outside of a repeated group, and it works. I can confirm that this error occurs only within a Repeated Group, not a normal group.
It’s a bit of a weird one, but as best I can tell the selected() function is not ‘typecasting’ the second param to a string [most other functions do this automatically, eg jr:choice-name() above in the same form…]. As a consequence, the validation logic is throwing a false-negative error, basically about the second argument not being a string [the pos() function strictly returns a number, but that shouldn’t really matter because typecasting will normally re-cast this to a string as needed…].
So my workaround above is basically to force the 2nd param to be a string, using the explicit string() function. That appears to make validate now happy, so you should be able to deploy my version. Of course, that’s all been rather hidden by the misleading error message that pyxform is currently returning…
Again, I dont know if this solves the original problem (!) - please report back if it does - but at least this should get you past this, um, speed-bump
FYI I’ll probably followup with another pyxform ticket for this, since it differs lightly from the misleading error message issue… Again, most other ODK functions already handle this typecasting for you, negating the need for having to add these explicit re-casts.
I confirm that I can deploy the form without any errors, and it works perfectly using string().
@hm11, please check Form Version 3 provided in this post thread to see if it fulfills your needs.
And then, I would like to inform other community members that if you need to implement a repeat group with a fixed position for each multiple-choice question, you can reference this post thread and use XLSForm Version 3.
hi @naylinsoe@Xiphware , I applied your version 3 form suggestion — it works, but only with a fixed repeat_count (i.e., seems its doesn’t support the count-selected() function). I just have to manually enter the number of options each time. nonetheless, it does the trick! Also works with both Enketo and KoboCollect. Thank you guys
]
