Sections.nsf RadioButton confusion finally understood.
I've had a rather complicated use for the Sections page... as I wanted to have two pages that were essentially the same functionality, but with options being screened.

i.e. I had two collections of Radio choices, that depended upon one annother for what would be enabled and what wouldn't, but didn't make sense to present together.

So I used the PageEx feature to wrap two Sections pages, seperately. However, the event handling function was the same for both... so it needed to be 'layered' with intelligence for both sets of Radio Buttons.

And since I was Using Sections.nsh feature for enforcing 1 and only one selection per group this became somewhat odd.

The structure in .onSelChange ( the event handler for a Sections page.. ) ( In fact the event handler for ALL/EVERY SECTIONS PAGE simultaneously ) causes you to need to trap all possible radio buttons whether they're on the page or not....

StartRadioButtons $var
RadioButton ${section_lablename} ; show on pg1
RadioButton ${section_lablenamename} ; show on pg1
RadioButton ${section_lablenamename} ; show on pg1
RadioButton ${section_lablename} ; show oh pg1
RadioButton ${section_lablenamename} ; show oh pg2
RadioButton ${section_lablenamename} ; show oh pg2
RadioButton ${section_lablename} ; show oh pg2
RadioButton ${section_lablenamename} ; show oh pg2
RadioButton ${section_lablenamename} ; show oh pg2
EndRadioButtons

; Options that have had SetSectionText ""
; operated on them won't show up.
; thus page 1 cleared all pg2 opttions and visa versa.

MessageBox MB_OK "We selected number $var"

I've had some confusion as to what affects the operation of these macros. I finally understood what was going on, and I decided to share my experience.

First off, the order in which you list the RadioButton calls depend on what Integer number is returned by the StartRadioButton marco... i.e. 0indexed through N-1 are the possible settings.... not the order their defined in the section definitions....or what is displayed... so if you're hiding several of them... you're available selections may come back 0 1 2 7 8 9 not 0 1 2 3 4 5

The StartRadioButton macro REQUIRES you pass it a handle. Which initially I presumed was just the handle for where the return code was put... but NOT SO!!!! The setting of that handle is what forces the de-selection of the existing option to be rejected. Thus enforcing something always being selected.

( In the case of my application where I didn't have a default selection, but wanted something to BE selected after something was chosen... this created confusion later.... You can see when I didn't presume to seed the macro... because I wanted it all to be blank initially... that the entire macro structure became unstable.)

After much frustration and finally forcing myself to comment the macros line by line, I realized that the initial var was supposed to be the CURRENT selected setting for the radio buttons... not just the [default].

So that meant that .onSelChange needed to store and reload an integer value each time the function was called...
so that the next it came back after a user-click, $var was the old ( last selected ) value. Otherwise, you got erratic behavior.

This REALLY needs to be commented better in the Sections.nsh code.