Jr:choice-name doesn't give a value when called from inside a repeat group

Support
1

Hi,

I have a form which has calculated fields to return the name of a previous selection into the following question. This form worked previously but now the calculated fields no longer work. The only difference is that i switched from KoboCollect to ODKCollect due to an issue with nested repeats in Kobo, but the calculate is no longer working on either platform.

Any advice appreciated…
Calctest.xlsx (18.2 KB)

2

I did a little debugging - the problem seems to be that

jr:choice-name(${Gear_ID}, '${Gear_ID}')

appears to return nothing when inside a repeat group, but does return the expected result when not inside a repeat group. I'm not sure whether this is by design, or a bug....

@ggalmazor, @martijnr, do you happen to know? Note, when inside a repeat the resulting XML looks like:

jr:choice-name( ../MeshSize_ID ,' ../MeshSize_ID ')

note the leading/trailing space on the second arg. Could this be throwing things off?

1 Like
3

The issue it that it worked previously and i still have a working instance of it on a running project. I have not changed anything but it no longer functions on newly deployed forms.

I need to make one or two small updates to a running project but i cannot deploy the new revision as this calculate function is no longer working and i cannot find out why.

I appreciate any help on this. Thanks

4

Not by design, I think. One could argue this function was dumped instead of designed (hence the apology in the spec). Looks like a bug in Collect and Enketo, nonetheless.

5

I haven't looked into this in detail but it's probably that the clients don't support the relative references now being generated by pyxform, right?

6

That's probably the cause; when did that change in pyxform?

I've open a javaRosa issue: https://github.com/opendatakit/javarosa/issues/435

@martijnr I'm not sure what the appropriate enketo component would be (enketo-core? enketo-xpathjs?) so I've not opened anything against yours yet.

7

Facing a similar challenge...any work-around please? Thank you!

8

Not AFAIK... I tried manually entering the full pathnames of the XML element (instead of ../ relative ones), ie

jr:choice-name(/Calctest/GearTypes/Gear_ID,'/Calctest/GearTypes/Gear_ID')

but it didnt help :frowning_face:

However, because all the options are numeric, what you might be able to do is put all the choice labels in a space-separated string - eg "20mm 25mm 30mm..." , and used a selected-at() to extract out the right one. eg

selected-at('20mm 25mm 30mm 35mm', ${Gear_ID}-1)

will return "25mm" when Gear_ID=2

[note the -1 because selected-at() uses a zero indexed array, but the gear IDs start at 1]. You'd have to drop the space between the "20" and "mm" for selected-at() to behave, but again this is just a workaround...

2 Likes
9

Thank you @Xiphware

Interesting to note that it is working seamlessly for select_multiple type of questions, the problem is with select_one questions within a repeat group.

10

Hi Xiphware,

Thanks for the feedback (and others). Your work around could work, it does for one round, but on selecting a second round in the repeat it give an error "Xpath evaulation: type mismatch this field is repeated....you may need to use the indexed-repeat () function.

I have tried several variations of indexed-repeat() but cannot get the syntax correct to get it to work with the Selected-at() function. Sorry i am new to this and not a programmer.

Any advice on the syntax to avoid this error. Thanks

11

@Rusti, you mentioned that this worked at one point. It would really help identify a fix if you could let us know a version in which it worked as expected. There are APKs for prior versions that you can download and install at https://github.com/opendatakit/collect/releases. Kobo Collect is a clone of Collect as of April 2018.

12

Hi LN,

I started using KoboCollect rather than ODK, i only switched to ODK recently due to a new error i was getting in Kobo (on a form which previously worked) with a nested repeat. When i switched to ODK, the nested repeat issue was resolved but i started getting an error with the calculated fields.

I have a working instance of the form still running on KoboCollecct 1.14.0a. The form was developed in xls. If i try deploy the same form as the one running to a new project in Kobo i get the error of 'Binding path [null] not allowed with parent binding of .......' this is in the same version of Kobo i had previously running v1.14.0a.

The same form is still currently running in Kobo on the tablets i originally set up. I have just tried kobo again and same error with trying to run the form. I get the same error in ODK v 15.0; ODK v1.16.2; ODK v1.17.2;

I switched to ODK and this error went away, but now i am getting the issue with the calculate fields.

ODK V1.18.0 the form works but the calculate field no longer works as in all later versions.

The original form (and running on kobo already on tablets) deploys in kobotoolbox. In Kobo collect it still gives me the binding path error. In ODK collect the form runs but the calculate fields do not work.

I do not know what else to try, the select-at() may work if someone can assist with the syntax to link with indexed repeat.

Thanks

13

If you could please post the form and I can try to play with it Friday when I free up.

14

Thanks, the full form or the shortened CalcTest form?

15

Thanks for the version details, @Rusti. I will try to take a look soon. In the mean time, the shortened CalcTest form would be helpful to see but it looks like a broken link now.

I've never used jr:choice-name because, as @martijnr mentioned, it feels like a hack. I can't see your form but what I'd try is explicitly building the XPath query for the choice name with something like jr:itext(instance('your_choice_list')/root/item[name=${MeshSize_ID}]/itextId). The catch is that this will only work if you have a choice filter on your choice list. You can read more about that and how to force it at Reverse cascading choice - #2 by LN.

16

thanks, here is the form i am trying to develop

Calctest.xlsx (16.9 KB)

17

Hi has anyone been able to look into this further?

18

Hello, I am back onto trying to find a work around for this issue again. I need to re-launch the survey and i am still running into the problem of the calculated fields not working inside a repeat. Has there been any further interest in finding a solution to this?
Thanks

19

Did you try @LN's solution at Jr:choice-name doesn't give a value when called from inside a repeat group - #15 by LN?

20

Do we have any metrics on how frequently jr:choice-name is used? I agree it is arguably a bit 'hacky', non-standard (hence jr:...) and, obviously, quite buggy... So if its not actually being used much then perhaps it is a good candidate to consider for deprecating?

3 Likes