I’m not sure what I’m doing wring here, and since I haven’t had a chance to test this code on Windows or Linux, I’m not sure if this is just something cocoa related (using the latest tip).
I have a really simply set up, just a DialogWindow, which is an ApplicationCommandTarget, and a content component, which is also an ApplicationCommandTarget.
The dialog window offers a command which is key mapped to F10, and that works fine.
The content component also offers a command, which is key mapped to F1. The key map works, I.E. the action is performed, but when I hit F1, or if I select the corresponding menu item, I also hear the system bell.
I can’t for the life of me imagine what’s going to be different about the dialog window, and the content component. Any ideas why I’m hearing an alert chime here?
No modal windows, just the one dialog, and content component.
If I had the command to the menu, and call it from the menu as a command target item, the beep happens at:
juce_mac_MainMenu.mm
line 154: [menu performKeyEquivalent: f35Event];
Since I know nothing about Cocoa, or ObjectiveC, that’s goobledygook to me, but I can see at least that it is related to the keystroke (even when a keystroke is not being used to launch the command - I.E. selecting the corresponding menu option).
As I say, the command will fire, but first the system beep will be heard.
Ah… that f35 thing is a bodge that someone suggested as the only way to get cocoa to flash the menu bar. I guess it’s having some unwanted side-effects. Ok, I’ll take a look when I get a moment…
Well I wouldn’t want to pass blame to quickly there, as the same thing happens when I remove the command from the menu, and try to run it as a simple key command.
Unfortunately I can’t work out how to follow the debugger through in that case, so I don’t know on which line the bell is sounded when the menu is taken out of the equation.
I’m pretty sure it has something to do with the way the keycodes are registered. ObjectiveC frightens me though, so I’m no sure how to follow it through.
Well oddly enough I just bumped into this again, only this time I realized what causes it, and since a search doesn’t bring up any solutions, I figure I’ll share.
Simple fix: don’t leave Mac system menus empty. I had a couple of empty main menu headings as place holders until I got around to adding actual items. This causes flashMenuBar() to fail when searching for an extant item. As soon as it hits one of the empty menu headings it seems to bail out noisily.
As a side note this may also occasionally cause the command manager to fail to invoke.
Now off to work out why FileChooserDialogBox emits a modal beep when it’s cancelled if launched from an async dialog box…
