GoListGroup handles the way it computes Bounds differently if TopIndex is -1 or >= 0.
If it is -1, it assumes there is no scrolling, and it computes the height (or width, depending on Orientation) to be the sum of the heights (or widths) of all the Visible children.
If TopIndex is >=0, it assumes something else is setting the height (or width) of the GoListGroup, and it manages the Visibility of the subitems so they fit (where TopIndex is the first Visible = true).
GoListGroup doesn’t care what the GoObjects are that are the children, so they can be complex, like other GoListGroups.
So, in the case of CollapsingRecordNode, there are 3 toplevel GoObjects in the sample (the title bar, First Section and Second Section). When TopIndex is 1, the title bar “scrolls off” (it’s actually just set Visible=false). When TopIndex is set to 2, all of “First Section” is gone.
The CollapsingRecordNode sample node is coded to assume TopIndex = -1, (variable overall height based on what is collapsed and what isn’t, rather than fixed height with a scrollbar to see things that don’t fit).
If you really wanted scrolling, you probably wouldn’t want the title bar to scroll away, and you’d want “First Section” to go away over 4 “scroll down” clicks, not 1.
To do that, you’d have to re-do LayoutChildren (as least) to interpret TopIndex so that it was looked at recursively with respect to GoListGroups within GoListGroups. But that doesn’t look easy…