When connecting a ComboBox to an AudioParameterChoice, set the parameter’s choices list automatically to the ComboBox.
This is in 95% what the user wants. If they want to have a different list, they can clear and set their own options, which is in line with the behaviour of SliderAttachment’s behaviour of the textToValue lambdas.
Also switch a button to toggle mode when connected with a ButtonAttachment, because with toggle off the attachment makes little sense either…
Ready to eat wrapped in a little PR:
It would be better to use
AudioProcessorParameter::getAllValueStrings() rather than casting to a choice parameter. That way it will work with all parameter types, rather than just one, and we can remove the
My main concern with this change is that it silently changes the behaviour of existing code. If a user is currently populating a combo box with custom contents before attaching it to a parameter, this change would overwrite the combo box contents without any build errors or runtime assertions. However, I agree that in new code, it makes sense to use the parameter options to populate the combo box by default.
Perhaps the attachment should
jassert (comboBox.getNumItems() == 0); before adding the new items, to alert developers that the attachment is about to overwrite their combo box options.
Great idea, I will amend the PR with these changes.
Done, I completely forgot about getAllValueStrings(). Thanks!
Any chance to get it upstream?
Thanks Daniel - this is awesome. When I first used the ComboBoxAttachment I was surprised, that it did not do this. You’ve got my vote.
Or maybe passing a bool named populateChoices to the constructor?