Simple way to disable commands when a dialog is up?


#1

It seems that all my keyboard accelerator commands still work when a dialog is up, and this causes issues.

In particular, I really don’t want people to be able to quit while a dialog is up, because my application crashes.

I can’t be the first person to want to do this, there must be an easy way I’m missing. I’ve looked at MenuBarModel, ApplicationCommandManager, DialogWindow and Component but none of them seems to have the right call…


#2

Is it your own dialog, or an OS one? (Just because this week I sorted it out so that on OSX the menus are deactivated when you open a file browser)


#3

It’s an instance of DialogWindow that I create!


#4

Well, I guess you’d want to make it take over as the first command target while visible, so that it can refuse to perform any commands that you don’t want it to.


#5

AHA!

Great idea. Thanks! I can even just tell my existing command target to refuse to do anything…

This leads to another issue with StandardApplicationCommandIDs::quit - but I’ll save that for another email…


#6

Unfortunately, after quite a bit of work this does not appear to fix my problem - though I have managed to disable all commands except the Quit command.

Somehow, the quit command seems to bypass my target manager entirely.

I don’t see how this can happen. JUCEApplication::getAllCommands(), JUCEApplication::getCommandInfo() and JUCEApplication::perform() are never even being called! And neither is my command target. Yet quit is still being called when I press Command-Q when my dialog is up.

It seems as if the Command-Q is entirely being taken care of in Objective C and my code is never called. :frowning:

I set a break at JUCEApplication::systemRequestedQuit - here’s the stack trace!

#0 0x00395152 in juce::JUCEApplication::systemRequestedQuit at juce_Application.cpp:92
#1 0x0056308d in juce::AppDelegateRedirector::shouldTerminate at juce_mac_MessageManager.mm:63
#2 0x0023a028 in -[JuceAppDelegate_1_54_27_s5d1u applicationShouldTerminate:] at juce_mac_MessageManager.mm:230
#3 0x96e78356 in -[NSApplication _docController:shouldTerminate:]
#4 0x96e77e7c in -[NSDocumentController(NSInternal) _continueTerminationHavingClosedAllDocuments:context:]
#5 0x96e77c5a in -[NSDocumentController(NSInternal) _shouldTerminateWithDelegate:shouldTerminateSelector:]
#6 0x96e77533 in -[NSApplication _shouldTerminate]
#7 0x96e770a5 in -[NSApplication terminate:]
#8 0x96c7ca26 in -[NSApplication sendAction:to:from:]
#9 0x96c7c8d9 in -[NSMenuItem _corePerformAction]
#10 0x96c7c5ca in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:]
#11 0x96d781c7 in -[NSMenu _performActionWithHighlightingForItemAtIndex:]
#12 0x96d77973 in -[NSMenu performKeyEquivalent:]
#13 0x96d76117 in -[NSApplication _handleKeyEquivalent:]
#14 0x96c6bfe6 in -[NSApplication sendEvent:]
#15 0x96eb721f in -[NSApplication _realDoModalLoop:peek:]
#16 0x96eb6945 in -[NSApplication runModalForWindow:]
#17 0x9714aad3 in -[NSSavePanel runModal]
#18 0x9714414b in -[NSSavePanel runModalForDirectory:file:]
#19 0x00406239 in juce::FileChooser::showPlatformDialog at juce_mac_FileChooser.mm:134
#20 0x00432053 in juce::FileChooser::showDialog at juce_FileChooser.cpp:112
#21 0x00433e68 in juce::FileChooser::browseForFileToOpen at juce_FileChooser.cpp:62
#22 0x0011d45e in rec::gui::dialog::browseForFileToOpen at Dialog.h:28


#7

Ah yes, when the OS sends a quit request directly, it goes straight to your JUCEApplication::systemRequestedQuit callback - you could add some logic in there that ignores it when a dialog is open.


#8

Bah, I should have that control was passing through a virtual method. Easy enough then to override!

Fascinating! This does fix my issue, and it almost does what I expected :smiley: but what happens now when you hit Command-Q when you have the file open dialog up only… is to close the dialog for you (but not close the program and not crash…)

(The quit is completely disabled for all other dialogs…)

This might even be desirable behavior - it’s certainly not undesirable :slight_smile: so I can mark this bug as decisively fixed.

I’ve learned something new from this, and that’s that the flow of control is quit different when a system dialog is up as opposed to a Juce-generated dialog - which makes a lot of sense when I write it that way.

Thanks again, have a great weekend!