Groups in a repeat stay expanded if last repeat got expanded?

[DougBrowning]

If I have a group set to compact and it is inside of a repeat.  On the first repeat it starts as closed.  If I expand the group in repeat 1 then go to repeat 2 it stays expanded.  Is there any way to change that so that it always starts compact on a new repeat?

thanks

[Anonymous User]

Hi Doug,

No, this is the expected behaviour. Across repeats each question and group inside the repeat are treated as the same objects, just with different values, so their status will be honoured as you navigate across the repeats.

Regards,

Phil.

[DougBrowning]

Thanks Phil but this is causing another issue now.  

If I have a nested repeat the current repeat number is also used across the top level.  

So in outside repeat 1 if i scroll to say repeat 3 in the inside repeat when I go to outside repeat 2 inside repeat stays at 3 also.  This means the user needs to scroll all the way back to the beginning every single time the outside changes.  We have 10 to 30 repeats so this is going to be trouble.  It also can create havoc with my repeat numbering that uses once(count()).

Any ideas this was is actually a big deal for us.  I would think that each inside repeat should reset to 1 when moving to a new outside repeat.

I really hope someday we can index and set the current repeat number.  Like a start_repeat number or something.

Slight correction maybe.  It seems to only start on a not 1 repeat if the last one was not on 1.  So if the last inside repeat was left at 6 then a new inside repeat goes to 6.

This should start at 1.  This is even happening if repeat count is not set and appearance is minimal.  Which makes no sense.

thanks

[AndyMcClary]

Hi Phil,

I'm running into exactly the same problem. When I go to a new repeat the nested (inside) repeat record retains the record number from the previous record. If there were 6 nested repeat records on the previous record the first nested repeat record that a user creates will be 6 of 6 rather than 1 of 1. Luckily there aren't actually five empty records created in this scenario (unless you scroll back through them), but it's highly confusing for our field crews.There's also some associated data weirdness with records 2-5 in this scenario, with auto-calculated date time fields not being populated. All in all it's a pretty serious glitch that is causing a lot of headaches for our field crews. 

Thanks,

Andrew

[DougBrowning]

As an update Phil has been helping a lot with this and other nested repeat issues.  They do now know it is an issue.

Unfortunately they are telling me that this will not be looked at, and hopefully addressed, until 3.12 - which will be at least next year.  I hope more people post on this as it is creating a lot of issues for me.

I have a few work arounds to try.

Set appearance to minimal so it starts with 0 records and a +.  But this is also broken in nested repeats so prob not for this case but it did help with some issues.

We have a relevant on one that asks did you collect this data? Yes/No.  If you toggle from No to Yes back to No then Yes it will reset the repeat and go back to 1.  Need to use a relevant on this.

In one case I was able to change from relevant to using the new body::esri::visible column and it helped.

Sorry I am not sure which one fixed which since I have been running into a number of issues with nested.

Hope it helps.

[AndyMcClary]

Thanks Doug! That helped put me on the right path.

After some experimentation it seems like the specific culprit is nested repeats where the relevance of the nested repeat itself is being controlled by a field in the repeat the next level up. Although in a lot of situations that is exactly what we want, I've found that groups are a pretty decent way to approximate this behavior. If you either wrap the nested repeat in a group and then put your relevant control on that group or put all the questions in the repeat inside a group and control that groups relevancy it seems to avoid the record numbering bug. 

Both of these solutions are a little more clunky from a UI standpoint but should be sufficient as stop gaps until a full fix is released. I'm going to play around with using the body::esri::visible field on the repeat in the beta version soon and see if that solves the problem. 

Thanks again for your help