[SOLVED] Renoise: Win32NativeFileChooser never exits thread

I’m having an issue which seems to happen in Renoise (Win10, VST3) only:

When using the native FileChooser on Windows, the destructor will call

    ~Win32NativeFileChooser() override
        waitForThreadToExit (-1);

However waitForThreadToExit(-1) will in ~50% of the cases never finish, freezing the plugin and host. The other 50% it will make the titlebar of the plugin flash for a few seconds and then close.

I am really clueless what’s going on here, maybe I am opening the FileChooser wrong somehow?

There’s a fix for this issue on the develop branch. Please try that out and let me know if you run into further problems.

Thanks for your answer! I built agains develop and I can confirm it works now.

In develop several parts of the API seem to be hidden behind a macro JUCE_MODAL_LOOPS_PERMITTED. I had to manually add this to my preprocessor definitions. Is this intended?

Also, is there a known date when this will be merged into the next stable JUCE version? My product is open source and I’m amidst a public beta. Changing my runners to built against develop right now might have unforseen consequences. Also, its is an extra step for users who want to build the project.

Yes, this is mentioned in the BREAKING CHANGES document in the repository. Modal loops are very dangerous in plugins, and are not supported on Android. Making this functionality opt-in rather than opt-out is intended to encourage users to write safer, more portable code by default, although the old modal functionality is still available if necessary.

We don’t have a concrete date, but we’re planning a new release in the next few weeks.

1 Like

If I may jump in, since the PopupMenu::show() hit me yesterday when updating:

Is there an alternative for popup menus in plugins?
Is JUCE_MODAL_LOOPS_PERMITTED a good idea in a plugin, if I need a PopupMenu?

I am especially concerned, since I use the PopupMenu in a public module that is used mainly in plugins…

I think PopupMenu::showMenuAsync should do what you want.

1 Like

Thanks, yes that works. Now I just need to find a replacement for juce::AlertWindow: dlg.runModalLoop()

Are any of the AlertWindow::show* functions suitable?

Unfortunately no. I need a text input field with addTextEditor(), which is not accessible by any of the static show() methods.

I think it would be trivial to create a showTextInputBox(), which will be useful to many others as well…

Here is how I use it:

BTW. Sorry for hijacking, but since the OP is solved anyway :wink:

I think something like this should work:

dlg = std::make_unique<AlertWindow> (TRANS ("New style class"),
                                     TRANS ("Enter a name:"),
dlg->addTextEditor (editorID, "class");
dlg->addButton (TRANS ("Cancel"), 0);
dlg->addButton (TRANS ("Ok"), 1);
dlg->enterModalState (true,
                      ModalCallbackFunction::create ([this] (int) { dlg.reset(); }));

Where dlg is a data member of type unique_ptr<AlertWindow>.

Took me a while to get it to show, addToDesktop and setVisible did not work, but centreAroundComponent did the trick.

All sorted, thank you @reuk !