PopupMenu doesn't have a setEnabled(bool) function?


Is there any reason why PopupMenu doesn’t have a setEnabled(bool) function? ComboBox has one which just finds the correct PopupMenu::Item and sets it. Why not make that a proper member function for PopupMenu?



Well, the way we’d encourage people to use PopupMenu is as a disposable object that you build when needed, rather than having one that you later modify. That’s why it doesn’t have any methods like that - and it wouldn’t make much sense to give it a setEnabled method without also giving it setColour, setCommandID, setItemText, etc etc!

The ComboBox is a bit of a special case in that it uses a PopupMenu internally because it happens to fit well for that use-case, but that doesn’t mean it’s how we’d recommend others use it.


As it happens, the only reason I need this is because I’m trying to add a submenu to a ComboBox and the only way seems to be to call getRootMenu() which returns the actual PopupMenu. And I need to be able to enable/disable a couple of items in that submenu.

So, ComboBox has no addSubMenu() and PopupMenu has no setEnabled(). Now what?


But ComboBox was never intended to allow sub-menus. In fact I’ve never seen a combo box anywhere that was anything other than a flat list of items!


I don’t understand, Jules. I’ve been using non-editable ComboBoxes as dropdown menus in my UI and they work very well. How would you suggest I add a submenu that can also be enabled/disabled?

In the JUCE demo you have a “Show PopupMenu” button that opens a PopupMenu with Submenus. Are you suggesting that every time I need a UI element like that I need to use a button to trigger a PopupMenu? It seems that ComboBox is perfect that. And there’s no DropdownMenu…


All I’m saying is that although ComboBox uses a PopupMenu internally, that’s just an implementation detail. The class was never designed to do anything beyond showing a normal, flat ComboBox list.

You’re welcome to abuse it and try to force it to do what you want, but you’re on your own with that! But in standard GUIs that you see everywhere else, if there’s a multi-level menu involved, that’s not a combo box, it’s generally done like in the demo as a menu triggered by a button.


Using a button to trigger a PopupMenu seems to be a thrown together DropdownMenu. The button should show the selected item unless you code that…but that’s what a ComboBox does!


I think that the main point of adding getRootMenu() was to give that extra possibility of adding sub-menus actually, cf the doc :

    /** Returns the PopupMenu object associated with the ComboBox.
        Can be useful for adding sub-menus to the ComboBox standard PopupMenu
    PopupMenu* getRootMenu() { return &currentMenu; }

And I have to say it’s been quite useful.

@pizzafilms a hack to update your menu could be

PopupMenu newMenu;
newMenu.addItem (...)

*yourComboBox.getRootMenu() = newMenu;


Thank you. That’s a start, but then I still can’t enable/disable items on the fly without having to rebuild the PopupMenu. ComboBox, on the other hand, has the ability to enable/disable items.


Sorry, am struggling to see why you can’t disable items… You can iterate the menu just like ComboBox does, it’s only a simple line of code to do that, right?


but why don’t you just call setItemEnabled() on the combobox actually?
are you saying it does not work with the combobox submenus items?


Sorry for all the turmoil. After a little clear thought, it’s WAY easier to just rebuild the ComboBox menu whenever I need to.

Thank you.


Yep, menus are really cheap and easy to build, I’ve found that’s almost always the cleanest way to do things.