Cabbage Logo
Back to Cabbage Site

Idea: string name support for radiogroup()

#1

The problem I have is using a radiogroup within the imported widget, it can’t be used more than once per instrument because all instances will refer to the same group and act as one.

If radiogroups() supported string names it would be far easier to use them within imported widgets safely, avoiding conflict with any other radiogroups() that may exist.

I would also suggest that radiogroups() within an imported widget’s cabbage section should get parsed to include the channel prefix, similar to channel() and identchannel(). Hopefully this would still be compatible with numeric groups, for example… radiogroup(1) could become radiogroup(“ChannelName1”)

#2

I see your point…I’l take a look

#3

Bringing this back up because I think it’s important for imported widget groups.

I have at least one imported widget group that I would like to import multiple instances of in a single instrument, but the widget group makes use of radiogroups. This is currently (afaik) impossible.

#4

I will look into this now. I don’t think it should be that tricky…

[edit] Might not be as simple as I thought s the JUCE Button::SetRadioGroupId() method takes an integer value. Trying to create a integer representation of a string won’t work because of the size limit on an int. I might have to use a look up table. It’ll be a bit more work. Leave it with me :wink:

#5

Awesome, thanks! This was one that I had run into before, and just bumped into again… figured I’d bring it up in case it was forgotten on the back burner.

#6

Think I have that sorted now. Just pushed a commit through. Watch out for the next successful build in Azure DevOps…

#7

Hrm, it doesn’t look like this is working. If I put a string in as the radiogroup(), the radiogroup declaration disappears entirely from the line when the widgets are imported. It still works appropriately when the ID is numerical.

This is tested with today’s “.4” build that fixes the button outline color in imported widgets.

#8

Seems to be working fine here. Try the attached.

CustomPlantImport.csd (651 Bytes)
plant.plant (2.0 KB)

#9

Confirmed, your example worked… and I was almost stumped, but then I change the radiogroup name to “ABCD” it no longer works.

I’m not sure, but I think it may have to do with capital case? On that note, would/should any other non-alphanum chars like -_+=/ etc be acceptable? I know I often use - and _ as separators in channel and variable names.

#10

Good spot. I’ll take a look. Pretty busy today but will try to get around to it.

#11

Great! No worries if it takes you a little bit… I’m just glad I’m not going crazy. I was doubting myself for a minute, I had stripped and tested a pretty sparse example before saying it didn’t work :spy:

#12

should be fixed now :wink:

#13

Hi @t_grey. I think this is Ok now. Can you try this one.

2020-03-05 10.32.46
2020-03-05 10.32.461731×956 470 KB

#14

This is the necro-bump I’ve been looking for :rofl:

I didn’t get to entirely run it through the ringer yet, but so far this looks great. The version number reported (from Lite) still matches my build from a year ago? I checked md5s of the app, it’s definitely new :wink:

It also looked like popuptext for these buttons didn’t show… but to be fair, it’s been so long since I’d paid these buttons much attention that I’m not entirely sure they were displaying popuptext before I updated either.

#15

Is this still the preferred way to do radio buttons? The example has some strange behavior. The “2” button doesn’t write to the Csound terminal.

Is there a way to make the radio buttons exclusive? Like, if I press 1 while 2 is pressed, then 2 should turn off.

Thanks!

#16

No, the preferred way is to simply add a radioGroup(int) to each button you want to form part of the radio group. They will automatically combine to create an exclusive grouping of button. The issues discussed here were to do with special imports.