There’s a button in the FL editor window border with the tooltip “Allow the plugin to handle keystrokes before the host does”. On Windows (you didn’t specify a platform so I’m guessing), disabling that allows the spacebar to work, even when the editor has focus.
At the moment, Windows keyboard handling in plugins works by hooking key events in the main thread. In the case of the AudioPluginDemo, when the editor fails to handle an event (like a space-key press), we’re correctly passing the event to
CallNextHookEx, so that the host gets a chance to process it. We can see that the host does receive the event, because it sends it back to the VST3 wrapper via
IPlugView::onKeyDown. The VST3 wrapper returns false, indicating that the event wasn’t used. Given that, at this point, the host knows that the editor has declined to process the event, I don’t see why it’s refusing to use the event itself.
It’s also worth noting that in this case, we return exactly the same result (kResultFalse) from onKeyDown and onKeyUp as the host checker plugin distributed with the VST3 SDK. However, FL will play when pressing space in the hostchecker, but not when pressing space in the AudioPluginDemo.
As far as I can tell, things ‘work’ in the hostchecker example because of the following in the vstgui4 windproc:
if (IsWindow (oldFocusWindow))
auto oldProc =
reinterpret_cast<WNDPROC> (GetWindowLongPtr (oldFocusWindow, GWLP_WNDPROC));
if (oldProc && oldProc != WindowProc)
return CallWindowProc (oldProc, oldFocusWindow, message, wParam, lParam);
When the editor is clicked, it remembers the window that had focus before this window, and manually forwards key events to that window. It’s not obvious to me that this is “correct” behaviour. JUCE, on the other hand, sends unhandled key messages to the editor window’s direct parent. To me, using the parent seems like a more reasonable choice than whichever window previously had focus. If we instead modify
forwardMessageToParent so that it sends the unhandled message to
GetAncestor (hwnd, GA_ROOT), then pressing space triggers playback. Based on that, my best guess is that the direct parent window provided by FL chooses not to handle the spacebar event by starting playback.
I don’t think it’s a good idea to change the recipient of unhandled key events in JUCE. Sending all unhandled key events to the root window, for example, could have unexpected repercussions. Other hosts might be in the opposite situation, and expect events to be forwarded to the parent rather than the root. To me, the current behaviour seems fairly reasonable.
If this is a deal-breaker, perhaps you could contact Image Line and ask them whether my analysis is correct, and if so, why the editor window’s direct parent doesn’t start playback when it receives a spacebar-press message.