VST3 plugin GUI eats keyboard messages in desktop application

I’m not not entirely sure but instead creating your native window try to grab the plugins native window instead with this

ComponentPeer::getNativeHandle()

Then when you have the handle

Component::addToDesktop

To see if it bypasses events

I tried the below two methods and both gave the same results:

        auto hwnd = p_main_component->getWindowHandle();
       
        AudioProcessorEditor* p_plugin_editor = mp_plugin->createEditor();
        p_plugin_editor->addToDesktop(0, hwnd);

        auto hwnd = p_main_component->getPeer()->getNativeHandle();
        
        AudioProcessorEditor* p_plugin_editor = mp_plugin->createEditor();
        p_plugin_editor->addToDesktop(0, hwnd);

The keyboard messages don’t seem to be automatically routed from the VST3 plugin native GUI into JUCE application. I needed to click the main application window with mouse before it started responding to keyboard presses again.

The main application DID update its GUI automatically in the background as it should, regardless of if the VST3 GUI or the main application was in focus. So this was an improvement.

The VST3 GUI did read the mouse messages automatically, but there was some odd behavior, like the messages were happening in two different locations at the same time inside the VST3 GUI.

Is it possible to addToDesktop inside your main component while

gettingHandle of the editor instead

Void * hwnd = createEditor()→getNativeWindowHandle()

addToDesktop(hwnd)

And if you are doing this make sure it gets added just once don’t make it visible twice I would assume is why the gui is triggering twice

I don’t see how that could be done. addToDesktop() works the other way around: the parameters given to addToDesktop() specify the parent object (and not the child) that will hold the component which calls the method.

My Last guess see if the plugin editor has a nested component then try to get that nested components native handle