Certain things in TD still need the panel “radio” value to work.
It seems to not be supported as expected using the “buttonRadio” widget.
- first is regular ‘button’ comps set to radio, works as expected,
- second is the regular buttonradio widget,
- third is four buttonwidgets set to radio inside a container
I tried with a sequence of four button widgets set to “radio down” button type.
Even more confusing is that the button widget has a “Button Group Dat” parameter that doesn’t seem to work.
The docs explain :
When a button is activated, it modifies the radio panel values of the DAT’s parent, not its own parent, since buttons can now be scattered in different components.
Am I missing something? shouldn’t the radioWidget and buttonWidgets in a groupDAT should change the panel.radio value?
Thanks for the report.
This is logged for a developer to look into it and get back to you.
The widgets don’t use the old radio panel value. In the case of buttonRadio, the equivalent is the Value0 parameter, which holds the index of the activated button. In the other example, there is no equivalent to the radio channel. You have to examine the Value0 pars of each button. Here is an obscure expression that will get you what you want:
[button.par.Value0 for button in op('buttonMomentary_1').par.Button0.eval().GroupButtons].index(True)
I’ll add an RFE to make getting this value easier.
I am trying to re-skin the stoner. A few areas in the stoner look at a radio panel value for the mode switching from the UI.
Converting this to widgets has turned out to be challenging because now I need to track down and replace all panel chops in the stoner looking at UI “radio” panel values with select chops looking at Value0 of my replacement widget radios.
I opened the bug because it seems like the radio button widget should be an easy replacement to the old “radio” button panel method, is there a reason a buttonRadio widget doesn’t use the panel.radio value and instead only uses the Value0?
If I could use the Value0 to set the panel.value, then it would be an easy drop-in replacement for the stoner’s old mode-switching UI.
Use this bind expression on the buttonRadio widget:
This is a feature mainly for internal use but will work well for your purposes. Bind tuples take (<object>, <attr>) for dependable TD values.
woah that’s some magic right there…
i’m, going to keep that in the back pocket
Maybe the most elegant hacky solution.
I’ll take it, but still feel the bug is valid.
More of an RFE but yeah makes total sense to set that radio panel value!
ok, can agree on that. I moved it
Widget values are always parameter based so don’t look in the Panel chop for Widget behavior. TUIK and widgets are not backward compatible unfortunately. This conversation is not ending here but Im just chiming in before we discuss this internally…
The easiest refactor if you want a widget value to be a chop channel is to use the Panel CHOP to grab the value Parameter then rename it to what you want - in your case radio.