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

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?

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.

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

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

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.

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

@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.

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

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

Thanks, the full form or the shortened CalcTest form?

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.

thanks, here is the form i am trying to develop

Calctest.xlsx (16.9 KB)

Hi has anyone been able to look into this further?

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

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?

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

... and one less non-XPath 1.0 function that I'll have to worry about implementing for libxml2... :grin:

Thanks for everyone's patience on this. I have a proposed fix at https://github.com/opendatakit/javarosa/pull/486 that should be released in Collect v1.24 in mid-October.

Thanks for the updates LN and Yaw, i will take a look at the beta release and see how it goes.

1 Like

I have a calculate field using jr:choice-name(${commodity_name},'${commodity_name}') to get the label from a select_one question 'commodity_name' within a repeat group. The select_one question has a choice_filter expression. The label is being displayed in ODK Collect v1.27.1 but not in Enketo v1.86.1. What could be the issue? Thanks.