Moving responses in a repeat group referenced to a select_multiple

Hi community

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.


@ambassador_training

1 Like

@hm11, could you also share with us your XLSForm so that we could test with the same?

1 Like

Here’s a screenshot of the form that I’ve used. For your reference. Thank you

1 Like

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.




Moving responses in a repeat group XLS Form.xlsx (10.3 KB)

@hm11

I found an alternative to using selected(). Instead, I used contains(), and it worked perfectly. Please see the XLSForm below.
Moving responses in a repeat group XLS Form V02.xlsx (6.8 KB)


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.

1 Like

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.


SimpleForm copy.xlsx (18.2 KB)

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.

Have a go and report back! :slightly_smiling_face:

[that, and the error message you are seeing is inaccurate, probably for historical reasons, and wasnt updated when non-literal value became supported. I’ve created a ticket to track this: Incorrect/misleading error displayed for an invalid selected() function 2nd param type · Issue #762 · XLSForm/pyxform · GitHub]

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.


Hmm… very interesting. I’ll investigate. :magnifying_glass_tilted_right:

1 Like

Hi @naylinsoe, can you please post your actual complete, new, modified XLSForm here so I can play around with it, thnx.

Hi @Xiphware Sure! Please find attached the XLSForm.
Moving responses in a repeat group XLS Form V02.xlsx (10.8 KB)

Try this, it should deploy successfully [but I make no claim as to whether it solves the original problem! :wink:]

Moving responses in a repeat group XLS Form V03.xlsx (10.9 KB)

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… :face_with_diagonal_mouth:

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 :slightly_smiling_face:

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.

2 Likes

Dear @Xiphware,

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.

Thanks.

2 Likes

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

1 Like