Hi,
I noticed some projects are using dedicated window wrappers to display plugins properly within Ableton Live on Windows OS.
if (((SystemStats::getOperatingSystemType() & SystemStats::Windows) != 0) && host.isAbletonLive()){...
Is it an outdated practice or is it better to wrap our JUCE plugin custom GUI inside a wrapper document especially for Live on Windows?
Thanks
I am curious about this as well, first time I read about this approach.
Is this meant to address the scaling issues for HDPI settings in Ableton?
What project does this code come from?
Actually It seems that it was for older versions of JUCE and especially VST2.4 type.
I found this code in CTRLR which I’m currently updating to 2025 specs 
I found an interesting post from the actual original developer on this forum, it’s dated back from 2012 (JUCE 3 maybe?) :
From what I understand it’s mainly a problem of keyboard focus, CTRLR was designed with an ancient version of JUCE that didn’t seem to handle “plugin requires keyboard focus” option in projucer and the related functions it enables since v5 or v6.
According to Gemini : A DocumentWindow creates a separate, top-level native window. This isolates your plugin’s UI from the host’s main window message loop to a greater extent. If Live was “eating” keystrokes from embedded plugin windows, a separate top-level window would bypass that. The wrapper would receive the keystrokes directly from the OS, and then it would be up to this wrapper to decide if it consumes them or tries to forward them back to Live (which is a whole other layer of complexity, but at least the plugin gets them first).
Interesting.
I kept the document wrapper window for Windows + Ableton Live + VST2 only for compatibility issue. It’s disabled for all other cases (OS, DAW, plugin type) and it actually works great like this.
VST3 API improved the way plugins handle the keyboard focus with IPlugView interface with onFocus.
