Create native window and embed it in component?

I wrote a Plugin Wrapper in a form that the Plugin doesn’t get “hosted” by JUCE, but actually wrapped, i.e. calls host<->plugin are mainly sent directly without JUCE wrapping/translation going on. The Wrapper “pretends” to be the “wrapped plugin”, including name, manufacturer, ID etc.

I want to extend the wrapped plugin UI with a “header”.

I got it going already, by creating a main component, dividing it by a header/label component (for testing purpose) and a component holding the wrapped plugins UI. I pass the components native window handle to the plugins dispatcher opCode OpenEditor, and it basically works, including resizing.

However, there is the odd plugin which doesn’t work. Mainly Applied Accoustics Systems plugins, they paint their content at the parents HWND, overwriting “my header”.

So, I need/want a native HWND where to put the plugins UI, preventing it from overwriting my header/lightweiht HWND.

I read about OpenGL doing it, but couldn’t figure out what to do, if even possible, please any help?

I thought about creating a desktop window holding the wrapped plugins UI, following the position of the main component (holding the header), but this doesn’t seem to work, aren’t there any “moved” callbacks for hosts HWND?

Also, I noticed some strange behaviours with for example iZotope Iris (1/2). When resizing the UI, then closing and reopening it, it is vertically misaligned. The host window is of correct size, but the content is drawn vertically misaligned. It isn’t specific to my wrapper, it misbehaves “unwrapped”, too.

But I don’t like this: I thought about NOT destroying the editor/components, but only hiding it when the editor should be closed, and showing it again when the Editor gets opened again. This should prevent this misbehavior.
Apart from memory consumption, is there any drawback? I mean, opening UIs shall be much faster this way, too…

Thanks for your help!

I can’t find the thread atm, but I remember jules saying, that you can use Component::addToDesktop() so it will have it’s own ComponentPeer with a window handle.

thanks, yes, indeed, a component added to the desktop DOES have its own Peer, but it also is a separate window/area on the desktop, and not “embedded” in a component.

Either there is a possibility to embed a separate peer in a components peer (OpenGL does that as far as I read here), or there is a possibility to have this separate peers window/area “follow” movement of the components peer…

I don’t know if either one works, and if so, how?

I never used it, but did you call both, addToDesktop AND addAndMakeVisible? Otherwise the component can’t follow it’s parent…
and also obviously the setBounds() in the resized callback…

addAndMakeVisible makes a lightweight comp out of a heavyweight. Calling addToDesktop after addAndMakeVisible again makes a heavyweight out of a lightweight, but as a separate window in the desktop.

Setting bounds (relative to parent=desktop) would initially place the separate window over the lightweight comp, but won’t follow movement, as the parent is the (non-moving) desktop.

That doesn’t work this way, at least not for me…

Ok, sorry. But worth the try :wink:

I have to apologize, it works!

I used addToDesktop on the component that shall contain the wrapped plugins UI, and gave it the HWND the host passes the OpenEditor OpCode. This way, the component is added to the desktop (becoming a native window) AND is attached to the host window!

At least on mac, it works!

Thanks!

but:

the UI then doesn’t receive any mouse, keyboard events… damn… I’m sure missing something?

Any ideas, some thoughts? I simply can’t get it to work, sorry

I haven’t tried that, but what might be worth checking

  1. the window flags for the heavyWeight peer
  2. if these are correct, maybe see if you need to register the Component as mouseListener by hand via Desktop::addGlobalMouseListener (component)

…and I don’t know, which is the preferred solution and what is a workaround…
Good luck

where is the final solution??

2 Likes