I have a select one list in a repeat where I want to stop, or warn, a user if they pick an item more than once during the repeats. This list is about 1,300 items.
I created a field that keeps a running list from my repeat
join(", ", ${SpeciesList})
I tried this constraint on the list not(contains(${AllPlants}, ${SpeciesList})) but it always triggers since it is in the list as soon as i pick it.
Is there a way to count the number of string occurrences? Or remove it from the check somehow.
Thanks for any ideas
Solved! Go to Solution.
I tried with no success. I ran it by esri. So we'll see what they find out.
I am also interested in not only counting unique selections across repeats, but also then using the returned selections to calculate a value. Has there been any advance in this in the last 14 months?
Sorry I didn't give an update about it. Well if you only use the mobile app then it works, but if you are trying to make it work in the web browser app then it won't. I have a case open with ESRI about that issue. BUG-000145359. The status of the bug is under consideration for the time being. So it won't change unless you elevate this bug.
Hi,
I don't know if it's still relevant, but I just encountered the same deign contraint. I try not to use JavaScript to have more maintainable surveys (not everyone can code in my team). So here's what I've done, for posterity 😀.
I started with a join like in the first post, and added a regexp testing if the answer to the select question is present twice in a that join, then placing that regexp within a not in the select constraint. This works well, even going back to edit previous repeat pages. The regexp has to be set on calculationMode=always so that it works when going back in repeat pages.
I'm attaching a excel file just doing this. I have incorporated this into a larger survey where choices are pulled from a FeatureService, it works well.
Edit - 2024-04-26: this does not work when the choices contain special characters, eg brackets, since the regexp interprets them as markers for the regexp itself. The solution would be to use literal escape markers in the regexp, \Q and \E. It does not work, and I raised the case with Esri UK/Ireland. It's up for analysis. Hopefully fixed soon.
There was a change to 123 that caused my code to fail the first repeat. Added new code to check for that. Plus added the , to the check to catch similar codes.