[SOLVED] Renoise: Win32NativeFileChooser never exits thread

Audio Plugins
1

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
    {
        signalThreadShouldExit();
        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?

2

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.

3

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.

4

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
5

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…

6

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

1 Like
7

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

8

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

9

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:

10

I think something like this should work:

dlg = std::make_unique<AlertWindow> (TRANS ("New style class"),
                                     TRANS ("Enter a name:"),
                                     AlertWindow::QuestionIcon,
                                     this);
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>.

11

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 !