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.
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.
Controls Groups = better name for Control arrays (since they’re not arrays but many people tried to treat them as if they were)
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.
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.
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.