Question

First off, some links (for those who want to try things out by themselves): I'm loading the Proteus VX VST plugin into my host, OpenMPT. The plugin works just fine, however it seems to steal some window messages so that clicking on the menus that are created by the host, or even clicking the close button has no effect. Clicking on the close button does not even trigger its "button-down" animation, so Windows probably doesn't receive any messages concerning the window actions. I know that other VST hosts like Renoise don't have this problem (clicking the window's close button works just fine there), so there must be a way to avoid this.

I suspect that Proteus VX installs a non-conforming window proc that probably forgets to call MFC's own window proc (and maybe also doesn't call DefWindowProc), but I have no idea how to find that out, let alone how to fix it. I tried saving the original GWL_WNDPROC before opening the plugin window and then restoring this proc right after the editor is shown, but that doesn't help.

Edit: The plugin must definitely do something dodgy; before allowing it to do anything with my window, I store the original WindowProc using

windowProc = GetWindowLongPtr(m_hWnd, GWL_WNDPROC);

and restore it after the plugin has done its window initialization business using

SetWindowLongPtr(m_hWnd, GWL_WNDPROC, windowProc);

This lets me use my own menus and the window's [x] button until I fiddle around in the plugin GUI a bit; I suppose that the plugin overwrites the window proc again as soon as it receives input focus.

Was it helpful?

Solution

Just in case anyone is stumbling upon this, the solution was to not place the VST GUI right in my own window. Instead, I place a static label in that window and then tell the VST to use this label as a parent.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top