Several plugin editors, same parent => stack overflow crash


I’m trying to display several plugin editors as child components sharing the same parent. So it is a different case than the Plugin Host sample where each editor has its own Document Window. I get a stack overflow crash due to recursive call of vstHookWndProc (I’m testing under Windows) as soon I add the second editor to the parent. This function is processing WM_WINDOWSPOSCHANING and is recalling itself continuously, just have 5 steps within user32.dll between two calls. I tried to display editors from different plugins and from several instances of one plugin: same result.

It is working fine if I remove the previous editor from the parent before adding the second… but then I can’t display several editors at a time. I have reproduced the issue from the Plugin Host sample by adding the editors to the graph panel instead of hosting them in floating document windows.

Is there any “normal” reason to be unable to add more than one AudioProcessorEditor to a parent component?

Any idea on how to fix this, or a workaround?



I this at my previous gig, and I don’t recall what it was. Maybe a current UA (Jim? Doug?) engineer will be able to share what I did. I think I added some check in the hook to make sure it didn’t get into the recursive state. And, if I recall, we only ended up getting the the Mac side to be able to host multiple plugins in a single window. I only spent a day trying to discern the problem under Windows, and had hoped once the crash was fixed, then it would work. But, the plugin GUI’s were a mess. I’m interested in any fix that you discover.

It’s a difficult problem, because there are so many VSTs out there which will blindly assume that they have their own parent window. You’d be ok doing this in 64-bit OSX because that uses NSViews, but I think that trying to force old Carbon windows or HWNDs to share a parent is always going to have edge-case problems.

Jules, what kind of assumptions do you mean? Can’t we put several ‘parent windows’ (ie. one for each VST) within one ‘grand-parent’ window?

Oh yes, you can do that. Sorry, I thought you meant you were trying to put the VSTs directly in a parent window.

Yep, I tried to put the several editors in desktop components floating over the main window, that’s working but it’s not easy to ensure that each editor window is in any case at the right place in front of the main window… And due to the plugin editor’s size, the editors often goes beyond the main window bounds.

Can you extend the idea of “put several ‘parent windows’ (ie. one for each VST) within one ‘grand-parent’ window”? My understanding is that children components are using the same message pump than the main window. So we need to use several desktop components or top-level window to ensure that each editor is hosted by different windows, avoiding the infinite recursive loop, right?

So… using top-level window equipped with a constrainer might be a solution, but I don’t want to see any window decoration (title bar…)…

I think TopLevelWindow indeed is the answer to that.
However, you might want to create a new class derived from it and disable menu bars and title bar from there.
You should be able to add such a TLW-derived class as a child component to your existing application window without further problems.