JUCE GUI for a win32 application plugin

I guess it's a long shot asking here but well...I am trying to see if it's possible to do a Reaper extension plugin with a JUCE-based GUI, but so far I am getting suboptimal results. Depending on what I have in the code, the plugin's GUI either shows as a new top level window or gets "intermingled" in Reaper's GUI, showing completely corrupted graphics.  Although the first mentioned way shows the GUI uncorrupted, it's completely unusable since the plugin window disappears when Reaper's own GUI is clicked and the plugin window has to be activated from the Windows taskbar to get it back. Setting Stay-on-top on the plugin dialog component keeps the plugin GUI visible, but has the downside the plugin isn't hidden when Reaper itself is minimized or put in the background, so not ideal to use that either.

I've tried MANY different variations of Component::addToDesktop, win32 API SetParent, as well as SetWindowLongPtr with GWL_STYLE/WS_CHILD and GWL_EXSTYLE/WS_EX_TOOLWINDOW(*), with different parameters, calling the APIs in different orders, but none produces the desired result : a tool window that stays visible and disappears together with Reaper when it is minimized or put in the background. With regards to Reaper, the primary thing I have to work with is the HWND of its main window. I am assuming I somehow must make the JUCE GUI be parented to that HWND. (That is how I have gotten it to work if the plugin GUI uses raw winapi or the Qt framework.)

So if by any chance someone would have any ideas on how to approach this further...(I know this is a fringe use case, so I am not really asking Jules to fix/change anything in JUCE to make this possible, unless it would have side benefits to more people.)

(*) Getting the HWND for the win32 API calls by using (HWND)dlg->getPeer()->getNativeHandle()

I've no idea how Reaper plugins work, so can't really help, but I'm sure it must be possible with a bit of hackery. If you get it going but require minor changes, let me know as I can often add small compatibility tweaks without breaking anything else.

Xenakios: maybe have a look at the WDL-OL framework, which is derived from older Reaper code?

Unfortunately there isn't really anything of great relevance and immediately usable in WDL or the forks for doing this. IPlug in the WDL OL fork is for making VST etc kinds of plugins. I guess with some effort the IPlug's IGraphics and IControl things could be adapted to be used for Reaper extension plugins, but I'd rather use something that is more suited to doing that, such as JUCE. In IPlug, for example a button control does not have a callback function that is executed when the button is clicked, it just changes an associated plugin parameter's value etc. So it's very messy to do stuff that works like a desktop application unless the IPlug code is changed a lot...

I am not sure how usable the WDL "virtual window" things would be. I tried those a bit once but without documentation and example code, it is all quite hit and miss...(I know Reaper uses those to some degree internally for windows where they need tons of GUI controls and they don't want to consume window handles of the system too much.)

I already know I could use the Qt framework for this, but the needed Qt dependencies are just HUGE, and they also need to be deployed as separate DLLs together with the plugin.

1 Like

Yeah, it might be I'd need to change something in the JUCE code (probably native window creation code), I will look into that at some point. GUI-wise the Reaper extension plugins are really just additional child windows. The GUI part in the plugin doesn't in most cases need to know anything else but the HWND of the Reaper main window. Likewise, Reaper isn't in most cases interested in interacting with the plugin windows. There are some exceptions to this if the windows are to be docked or if special keyboard handling is desired etc but I am not thinking that far at the moment, I'd be happy to just get a JUCE based window to work as a child window properly... 

By the way, this is currently for my own private testing only, but in case I get something working and want to publicly release plugins using JUCE, I wonder how the GPL licensing will work for it? As much as I would like to, it's not currently feasible for me to get the JUCE commercial license, so I'd go for GPL and release the plugin source codes at Github or similar. The Reaper SDK header files would seem to be licensed so that they don't conflict with the GPL but is that enough?

Just as an update for this, I was finally able to figure out the needed things to get the window behavior I want, but unfortunately not the look I want. However, I am willing to live with this for now...Achieving this didn't fortunately in the end require changing the Juce win32 windowing code. (Might maybe be needed if I want to fix the remaining visual defect...)

So the problem is that I need to have both the native title bar AND the Juce component title bar visible inside Reaper, which is visually quite redundant and wastes space :

edit : Hmm, now thinking about it...Could it be the problem that my GUI is a subclass of DialogWindow and not Component?

Could it be the problem that my GUI is a subclass of DialogWindow and not Component?

well yes.. If you use a DialogWindow, then obviously that's what you'll get!

But if I make the GUI just a Component when the thing is run as a plugin, will I be able to resize the window, have the frame that has the close button and have some way to react to the user clicking on the close button and so on...? (With the way it's currently working, I do get those desired behaviors...)

But plugins don't need a close button.. (?)

And you can use a ResizableWindow or ResizeableCornerComponent if you need that.

They do need the close button in this case, because the plugin GUI is supposed to be a "tool window" inside Reaper. Reaper itself doesn't provide "framing windows" for the extension plugins...(It does provide those for VST style plugins, of course, as those kinds of plugins expect that.) And also there needs to some area in the plugin GUI that allows moving the window around. (Which the title bar(s) provide(s) with my current solution.)

Setting the title bar height of the dialog to zero works to hide the Juce title bar, so I'll go with that for now!

Why not just use a ResizableWindow?