Hi, in the docs there’s a very insistant:
Note that you SHOULD NEVER USE THIS METHOD
Looking at the show() calls though, they’re only a very thin wrapper to runModalLoop, so this mean we should only ever call show() or is show() is bad too?
What are the alternatives to calling runModalLoop() for popping up windows?
do it async, in Android is the only way:
AlertWindow::showMessageBoxAsync <-features a callback, do same stuff on other objects that need it
thx - it appears you can do that for alerts, but the FileChooserDialogBox doesn’t appear to have any async methods on it.
Is this for a GUI App or a Plug-In?
There’s no way except to roll your own Component… I haven’t yet found a safe way to dismiss the FileChooser in a Plug-In if the Host is quit while the Chooser is open. It may be possible though… I do see it used in one JUCE based plugin.
I haven’t been able to get that to work for a plug-in
getNumModalComponents() in ModalComponentManager::cancelAllModalComponents()
always returns zero.
You can see my other thread about AsyncQuitRetrier
I think you can call
enterModalState(true, callback) to show the dialog, and handle the file selection in the callback.
I don’t think you can do that with a Native Chooser
No, I was talking about the
FileChooserDialogBox, which is a juce component.
Native filechoosers on Windows always start a modal loop.
Yes, this is an annoying feature of native file choosers - at some point we’ll revisit them and try to find some asynchronous solutions for each platform.