[BR] Alert sound selecting an item in mac menu

I have an alert sound each time i select something in the menu bar (on macOS 11.6).
Furthermore setting a custom menu in Apple’s menu (e.g. see below) is broken now.

juce::PopupMenu menu (MenuModel::createAppleMenu (commandManager_.get()));
juce::MenuBarModel::setMacMainMenu (menu_.get(), &menu);

It is broken since that commit:

It seems strange that i’m the only one with that problem. :thinking:

I’ll try to make a simple example to reproduce it.

Here a “minimal” example that bug.

  1. Selecting the “Bar” tiem in the “Foo” menu results in an alert sound.
  2. Moreover the “Pregerences” item in Apple’s menu is disabled now.

I compile with Xcode 12.5.1 on macOS BigSur.

The commit reported in previous post breaks it. Am i doing something wrong?

Bip-master.zip (6.8 KB)

The new beeping sounds do indeed appear to be a new bug. I’ve got a potential fix, so hopefully that will be available at some point on Monday.


I think the ‘preferences’ menu is actually working as intended now. The menu returned from MenuModel::createAppleMenu has isEnabled set to false on the “Preferences…” item. Previously, items in the main menu did not respect their enablement state, which is why the item appeared to be enabled (it should have been displaying as disabled).

To make this work as you expect, the PopupMenu will need to be tweaked so that its items have their isEnabled members set appropriately. At the moment, isEnabled is set to false because the menu is initially created at a point where the BipComponent (which handles the preferences command) is not a viable target component.

Here are some ideas:

  • Iterate the PopupMenu after creating it and set isEnabled directly to true for any items that you really want to be enabled.
  • You could postpone creating/setting the main menu items until after the BipComponent has become visible and grabbed keyboard focus.
  • Change the target of the “Preferences…” command so that the target is definitely viable at the point where the menu is created. This might mean overriding the ApplicationCommandTarget functions directly on BipApplication to handle preferences there.
1 Like

I pushed a fix for disabled “Preferences…” item using your third approach.
I’ll try the beeping sound fix as soon as available. :grinning_face_with_smiling_eyes:
Anyway thanks for your help.

The fix for the beeping sound has now been merged:

Please try it out and let us know if you encounter any new issues.

1 Like

It seems to work fine now. Thanks!

Hey @reuk, is it impossible to have dynamic enable state for items in the Mac main menu?
Here is what I do:

PopupMenu macExtrasMenu;
macExtrasMenu.addCommandItem( getCommandManager(), cmdPreferences );
view->setMacMainMenu( view, &macExtrasMenu );
view->getMacMainMenu()->setApplicationCommandManagerToWatch( getCommandManager() );

As you mentioned, I also have the issue where the command target is not viable at the time I create the Mac menu, so Preferences appears disabled.
I added this:

PopupMenu::MenuItemIterator itr( macExtrasMenu, false );
while ( itr.next() )
{
    if ( itr.getItem().itemID == CommandIDs::cmdPreferences )
    {
        itr.getItem().setEnabled( true );
        break;
    }
}

It enables the command in the Mac main menu as expected.
This issue though is that this command is supposed to be disabled under some conditions. setApplicationCommandManagerToWatch seems to have no effect: the command info is never requested.
I even tried to perform manual enable/disable on a timer using the iterator method above, but it seems that once the menu is created, you cannot update the commands enablement.
What am I missing?

I don’t think this will work automatically at the moment. The menu normally updates when the MenuBarModel changes in some way - however, there’s no way to regenerate the extra Apple menu items from the mac main menu. The menu can only be supplied in the call to setMacMainMenu, and cannot change after that.

Perhaps in the future we could look at adding a virtual function to MenuBarModel that would return extra Apple menu items. That way, when the model changed, we could regenerate the Apple menu (including enablement states) too. Not sure when I’ll get a chance to look into this at the moment - things are a bit busy here with ADC stuff at the moment.

In the meantime, you could try just calling setMacMainMenu and passing a new extras menu every time you want to change the enablement of the preferences item.

Understood, I’ll update the menu with setMacMainMenu for now. Thanks for your detailed answer!