Hosting 64Bit Plugins: Window Goes Black

#1

Hi Jules,

When running PluginHost in 64bit, and loading 64bit VSTs, I’ve noticed that some plugin windows show up black after reopening them for a second time (or more)… :shock:

Below, MLimiter (from the MFreeEffectsBundle) demonstrates this:
[attachment=0]Painting It Black.png[/attachment]

#2

This issue may have not been related to 64-bit plugins only, but commenting out the code that checks if the plugin’s handle is that of a window, and destroys it, does the trick (in this case anyways)… As it was, the handle of the MLimiter plugin’s instance was getting nulled, so the next time around in openPluginWindow(), the plugin handle would be 0 (see line 2238).

//juce_VSTPluginFormat.cpp - VSTPluginWindow

void closePluginWindow()
{
    if (isOpen)
    {
        #if ! (JUCE_MAC && JUCE_SUPPORT_CARBON)
        JUCE_VST_LOG ("Closing VST UI: " + plugin.getName());
        isOpen = false;

        dispatch (effEditClose, 0, 0, 0, 0);
        stopTimer();

        #if JUCE_WINDOWS
        //#pragma warning (push)
        //#pragma warning (disable: 4244)
        //if (pluginHWND != 0 && IsWindow (pluginHWND))
        //    SetWindowLongPtr (pluginHWND, GWLP_WNDPROC, (LONG_PTR) originalWndProc);
        //#pragma warning (pop)

        //if (pluginHWND != 0 && IsWindow (pluginHWND))
        //    DestroyWindow (pluginHWND);

        pluginHWND = 0;
        #elif JUCE_LINUX
        pluginWindow = 0;
        pluginProc = 0;
        #endif
        #endif
    }
}
#3

May be worth noting that those lines of code predate jucequake - so it’s not entirely apparent why they’re there in the first place… :? Was the VSTPluginWindow an actual stand-alone window at one point, and not just an AudioProcessorEditor component?

#4

Agh… So the plugin is caching its HWND after the host closes it, and trying to re-use it again later!? That’s pretty nasty behaviour.

But it does raise the question of whether the host or plugin is responsible for calling DestroyWindow… There’s no point in expecting the VST API to say anything about this, but… assuming that this plugin must work correctly in at least some other hosts, then those other hosts mustn’t be deleting the window. So I guess we should copy that behaviour too.

(You’d want to leave the SetWindowLongPtr in there though, and just not call DestroyWindow)

#5

Any docs on VST hosting are rather vague when it comes to windowing: there doesn’t seem to be information on who is supposed to handle destroying the window (which is peculiar), as you pretty much predicted.

I looked into various small host examples, including Audacity, and oddly, I haven’t found a single call or reference to DestroyWindow() in the code… Also, I tested the same plugin in FL 10 and Audition 3, and it works absolutely fine, so I’d say the hosts are probably not deleting the window.

Ah right! Looking at it again - I see why that’s important to be there… :smiley:

#6

Thanks for the research, I’ll roll that change in there…

#7

Glad to, thanks Jules