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…
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 dynamic_cast.
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.