It seems that it is not possible (only on OS X, on Windows it works) to use setAlwaysOnTop(true) in a DocumentWindow holding a plugin’s editor. You can try to add setAlwaysOnTop(true) in the last line of the PluginWindow constructor in the PluginHost, and it will crash or the window with the plugin will be empty. Weird…
PS: Pluginhost crashes in Release mode on OS X (can’t get it to run because of some assertion failure), only works in Debug mode.
That’s not surprising, because on OSX to change the window’s mode, it needs to actually delete the OS window and create a new one, so any views within it are going to get messed up. Can’t think of a good workaround for that, TBH…
But then it should be as simple as to first call setAlwaysOnTop(true) and then use setContentComponent() afterwards!?
This method seems to work at start, but the plugin sometimes tends to go down by the same amount of pixels as the Title Bar height of the DocumentWindow it is contained in. This always happens when I click on another plugin’s window. And it only happens with VST plugins. Why is that? :?
Even changing using setVisible(false) and setVisible(true) again on a DocumentWindow containing a plugin produces the same effect.
Keeping plugins always on top seems like a “must”. All hosts do it (Logic, Cubase, Ableton), so why can’t JUCE do it? I don’t care if it is a native window or a JUCE window. But having to click everytime on a damn button to make a plugin visible again is out of question.
Can’t think why it would move the plugin down, though an always-on-top window is actually a different class of window on the mac.
Well, try it. I does.
How do the other OS X Carbon-based hosts keep their plugin windows always on top? I really need to figure out how I can do this with JUCE on Mac, so any help appreciated.
It might be possible in Cocoa if you can grab the top-level NSWindow - that class has some extra tricks that Carbon doesn’t give you.
And what about all old apps that were written in Carbon and have always on top plugin windows? How they manage to do it?
It is possible to get an NSWindow pointer to a carbon window. Mixing the two is pretty precarious though!
So why does changing using setVisible(false) and setVisible(true) again on a DocumentWindow containing a plugin make the inner of the plugin move down (and the same thing happens when I click outside of the plugin window and it is greyed because it does not have the focus anymore)?
I tried it again, and this really happens. The plugin window stays on top though (but only if I don’t use the native OS X title bar).
Must be a mix-up between the client area position and the overall frame position. I’ll make sure this will work ok in the new cocoa stuff.
I’m getting the same error on Linux (Debian Buster 10.6) 12 years later 
I can reproduce it as suggested by @zamrate by adding the setAlwaysOnTop(true) instruction here, right after setVisible(true).
Additional remarks:
setAlwaysOnTop(true) instruction before setVisible(true).I’m currently looking into how the VST3 editor is different than the VST2 counterpart. Any hint on this would be appreciated.
