FileChooser a problem in plug-ins?

I read several times that i should not open modal dialogs in plug-ins. Is this rule also valid for the file chooser dialog? If yes, is there a component that has the same behavior with a async callback?

Unfortunately it's hard to find an alternative for the file-chooser, so if you want a native one, you'd probably just have to risk it. Though I guess you could use the juce non-native file-chooser and run that asynchronously modal.

Thanks for the quick response. I don't need the native one. Do you mean the juce FileChooserDialogBox ? How can i run this one async. I only see the "modal" show() call. Is there a out of the box solution?

You'd have to create one and call enterModalState on it yourself with a callback.. I should probably write some kind of helper function for that at some point, but it's not too hard to do.

I tried following code, but the windows does not show up, just some flicker:

        FileChooserDialogBox dialogBox (
            "Open some kind of file",
            "Please choose some kind of file that you want to open...",

        dialogBox.enterModalState(true, ModalCallbackFunction::forComponent(LoadFileCallback, this));

Is there something i miss?

Edit: The component closes and calls the callback immediately after i open it. Think i don't understand what enterModalState does. Any ideas are welcome.

Well yes.. if you create it on the stack it'll be deleted immediately when the function returns!

sure :) Thanks for the input. It works now.

I create the dialog on the heap with "new" to keep it alive until the callback will be called. I guess i need a class instance of the dialog and the browser in the component that uses the dialog and delete it manually in the callback function. Is that the right way to do that?


Something like this?

    ScopedPointer<FileBrowserComponent> browser;
    ScopedPointer<FileChooserDialogBox> dialogBox;
    ScopedPointer<WildcardFileFilter> wildcardFilter;



        this->wildcardFilter = new WildcardFileFilter(wildcard, String::empty, "audio files");

        this->browser = new FileBrowserComponent(
            FileBrowserComponent::canSelectFiles | FileBrowserComponent::saveMode,

        this->dialogBox = new FileChooserDialogBox(
            "Save File",


    static void FileCallback(int result, FileDialog *component)
        if (result > 0 && component != nullptr && component->browser != nullptr)
            component->callback->execute(component->index, component->browser->getSelectedFile(0));

            component->dialogBox = nullptr;
            component->browser = nullptr;
            component->wildcardFilter = nullptr;


I have many troubles with the native dialog window when using the FileChooser. I use it in my code like this:

`FileChooser fileChooser (“Please select a source file…”, File::getCurrentWorkingDirectory(), “*.my_extension”, true);

if (fileChooser.browseForFileToOpen())
    return fileChooser.getResult().getFullPathName();

The problem is that in some DAWs when the user chooses a file, clicks on the “open” button, the file is applied in my plugin accordingly, but the dialog window is never closed. The application doesn’t crash, but the sight of the user is blocked by this window…

This happened (so far tested) in VST and AU in: AU Lab 2.2.2, Audition 2015.2, Ableton Live 9.6.2 Trial
(MacBook Pro (Retina, 13-inch, Late 2013) with OSX 10.11.5)

This problem doesn’t appear in: Plugin Host from Juce, Audacity 2.1.0, Garageband 10.1.2

It also works happily in all DAWs if I don’t use the native dialog (@param useOSNativeDialogBox = false)

Any ideas how I could solve the problem? (No, I don’t want to use a non-native dialog…)

As jules said, you have to use it on your own risk. I can’t imagine that it is not possible to fix that without a hack. You maybe also run into issues where the window is behind the plugin. You maybe avoid any modal dialog by design.

Well, I understand that but I can’t imagine that there is no any other solution. I have no problems with canceling the dialog, also no problem with modal dialog windows for saving files for example. It’s just the openFile Dialog creating this problem.

The interesting point is, that the application is still available when I click on the “open” button in the file dialog, so the instance of the modal dialog should be destroyed… But visually, the window does not disappear… Is it an OSX Finder problem maybe?

I also tried to actively destroy all modal components, but that didn’t work either… I’m happy for any little idea. And of course, if there is no other way, I apparently have to abstain form using the FileChooser class at all…

I just tried with a vst under 10.11 with live 6.2.1, but I can’t reproduce.
when I select a file and click open, the file chooser disappears.

I just added a button in the demoplugin, with the following:

void buttonClicked (Button*) override
    FileChooser fc ("filechooser test",
                    File::getSpecialLocation (File::userDesktopDirectory),
                    "*", true);


Can you reproduce with such minimal code?

The advice with plugins is always to avoid popping up windows, even if they’re not modal - there are a million edge-cases in different hosts that can go wrong when you throw unexpected windows at them. If you’re using a non-system dialog, then you should put it inside your plugin editor, not make it a separate window, so that it’ll work under all circumstances.

On OSX Sierra Logic X crashes if you try to open the native file browser. At least on my system. A user reported this too. So, this isn’t an option anymore.

It would be great to have an improved FileChooserComponent in the JUCE framework. One with a directory tree on the left and a file list on the right.

it seems to work here with the example code above, sierra and logic 10.2.4 + last juce. Does it crashes every time for you, or every once in a while?

I use a lot of non-modal windows (with always on the top) in my plugins (its also the only reliable way to get keyboard input across all hosts), and it works very well (don’t know any existing problem at this time). Also its a very common technique. Of cause the lifetime of these windows has to be linked to the plugin gui.

But of course any modal dialogs/windows should be avoided

It crashes every time. But i still use logic 10.0.0. The user that reported the crash was using Logic 9 and OSX 10.12.1 64bit. I think our plugins use the latest master JUCE release (maybe two months old). Other hosts don’t have that issue, so i think it’s related to Logic / Sierra.

Good to know that it works with the latest releases.

This may be a Logic 9 and Sierra issue related to iCloud Drive:


1 Like

Thanks for that. It also crashes when you try to save a logic project. That’s a surprise… So, we can still keep our native file choosers for a while :slight_smile:

Edit: It works with disabled iCloud.