Editing records with repeats based on # of select_multiple is causing problems (web app version)

[MaryGraceMcClellan]

The survey I've created is using a formula to generate the repeats based on how many answers were chosen in a previous question. The repeat_count formula looks like this: 

count-selected(${projects})

Then, within each repeat, I am pulling out values ("project_name" in the example below) from the select_multiple based on the repeat index, like so: 

repeat_index = position(..)
project_name = selected-at(${projects}, ${repeat_index}-1)

It works really well when the survey is first being created, but the intention is to go back and edit the records through an embedded version of the survey in an Experience Builder. The issue I end up with is, as more projects are selected, the indexing gets messed up and the values are inserted based on where they are inserted into the list.

For instance, the first item might be "PROJECT3", and all the relevant details are added to the first repeat for that project. Then, the user goes back to edit the record and adds "PROJECT1" to the select_multiple answers. Now the first repeat still says "PROJECT3", but so does the second repeat. So then I recalculate the first repeat and it does become "PROJECT1", but the details are all mixed up now. 

I hope this is making sense! Has anyone seen this behavior and come up with a good fix? I've found that some fuinctionality (such as calculationMode) that might be helpful is not available in the web app version of Survey. 

[abureaux]

I believe that this can be calssified under "known functionality". Basically, you have two related issues.

1. When a repeat item is deleted, the index(..) gets messed up
2. When working with calculates within repeats, the calculates only fire for the currently active repeat item. If you manually scroll through each repeat item, the calculates will re-fire. If they don't (and you manually scrolled through the repeat items), then you just need to add calculationMode=always to the calculate.

[DougBrowning]

I have found that changing repeat_count on the fly wipes the data.  Not sure if this is what you are seeing but repeat_count really does not like being changed.  Also it loads all the repeats at once which messes up a lot of calcs.   It got to the point where I stopped using it and instead use count() in a constraint.  It is just way more reliable.  Hope that works for you.