If I create 3 control groups of 4 radio buttons each and placed them all on the same window, I apparently have 12 radio buttons that are all connected.
So, what is the purpose of a control group? Is this just a new way of referring to an array of controls to differentiate it from an array object?
Rather confusing…
radio buttons are grouped based on their container
put the 3 groups on one canvas each
So just like ye olde tymes…
I’m sure that I missed a discussion (or three) about Control Groups. Seemed to me that grouping them as they are displayed in the project hierarchy was tying them into an operational group. I was mistaken.
It might have used to have been influenced by control groups at one time.
But even in a Carbon app in 2012r2.1 this requires a canvas to get the grouping behavior.
That’s what I meant by Ye olde tymes. But, back then, we didn’t have Control Groups, we had Control Arrays and it was widely known that we had to encompass things like this to get the mutually exclusive pick selection.
I was just mistaken in my thinking that the new “Control Groups” actually grouped controls for mutual exclusion.
As I see now, Control Groups simply allow you to have a single Action (or other) event for specific controls based on the index of the selected control.
I think it was mostly a name change to not confuse as many people, since a “control array” wasn’t really an array. It was a group of controls that share event code. Thus the name change, to make it clearer. I don’t think any functionality changed.
[quote=146196:@Tim Jones]That’s what I meant by Ye olde tymes. But, back then, we didn’t have Control Groups, we had Control Arrays and it was widely known that we had to encompass things like this to get the mutually exclusive pick selection.
[/quote]
Controls Groups = better name for Control arrays (since they’re not arrays but many people tried to treat them as if they were)
But why?
Seems cumbersome surely they could be grouped internally by their name?
But you might want to go the other way. The control group might be one button in each button group. The next button in the button group would be a different control group, etc. I think grouping radiobuttons by parent is the right way to go.
???
All the buttons with name GroupA are one group, all the ones with GroupB are another, doesn’t matter how you arrange them.
Most flexible and logical approach.
Using a parent control is awkward
I guess it’s a matter of personal preference, but I just can’t see using a control group for a group of radio buttons. The only way to distinguish them would be by index? That seems rather fragile. I would want each button in group of buttons to have its own event.
Now, I might replicate that group of buttons on several pages of a PagePanel to present a slightly different interface depending of certain factors. Then I would use a control array for each button in the group, with the index matching the page.
Besides, if I had more than one group of radio buttons on the interface, I would probably put each group on a GroupBox anyway, to visually distinguish them and provide a descriptive label. So they automatically get a separate parent. I don’t see the issue there.
You all mean “Control Sets” when you are saying “Control Groups”, right?
Yeah, whatever they’re called now. 
For what it’s worth I can count on one hand the number of times I’ve used Control Sets in Xojo in 14 years. The mechanism is fragile, in my opinion, because it’s all based on index, that from my experience, changes too often. We prefer to use Container Controls.
Don’t forget that control groups (arrays) predate container controls by a lot, and that for a long time after the intro of container controls (until Xojo) they were a Pro only feature
So for a long them and until Xojo, for many control groups, were the only way to create controls dynamically.
So yes container controls make them less necessary … but sometimes ContainerControls seem like overkill… I still find control groups more convenient for some simple uses… That is when i only need dynamic controls of a single type on a single Window ( and don’t see a need to reuse the code)… Also sometimes having shared event code can make writing and managing the code simpler.