# Not possible to intercept keystrokes when hosting some plugins

**URL:** <https://forum.juce.com/t/not-possible-to-intercept-keystrokes-when-hosting-some-plugins/52913>\
**Category:** General JUCE discussion\
**Created:** [September 7, 2022, 4:54pm UTC](https://forum.juce.com/t/not-possible-to-intercept-keystrokes-when-hosting-some-plugins/52913 "2022-09-07T16:54:12Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![benstaton](https://avatars.discourse-cdn.com/v4/letter/b/9fc29f/32.png) [@benstaton](https://forum.juce.com/u/benstaton)\
**Post date:** [September 7, 2022, 4:54pm UTC](https://forum.juce.com/t/not-possible-to-intercept-keystrokes-when-hosting-some-plugins/52913/1 "2022-09-07T16:54:12Z")

</div>

Hi all,

Our JUCE app hosts VST3 plugins using `juce::VST3PluginWindow`, which works well for the most part.

Like many audio apps, we use the Spacebar as a keyboard shortcut for starting the transport (among many other command shortcuts). Unfortunately, when focused, some plugins appear to swallow keystrokes altogether, so our app never gets chance to intercept them, even at the lowest level (e.g. on Windows, I added breakpoints to `juce::HWNDComponentPeer::peerWindowProc()` which never get hit).

I even used the Visual Studio Spy++ utility to monitor Windows keyboard messages, which confirmed that some third party plugin UI windows are indeed _consuming_ WM\_KEYDOWN/WM\_KEYUP messages.

Obviously, I’m seeing this on Windows, but it may also be a problem on Mac. Not easy to tell, since it’s plugin (vendor?) specific.

Thankfully, most plugins behave themselves, handling keystrokes they need and letting unused keystrokes find their way up to parent (JUCE) windows, but there are plenty of popular plugins that exhibit this behavior, including:

- Waves Abbey Road Chambers Stereo
- Eventide 2016 Stereo Room
- Arturia Tape Mello-Fi
- Roland Zenology FX

This makes it impossible for us to handle app-wide keyboard shortcuts/commands while some plugins are focused.

I can’t find a way to fix it that doesn’t involve using low level OS specific workarounds, such as keyboard hooks or subclassing on Windows. Something along those lines may well be necessary, _ **but I would argue it should be handled internally by JUCE itself** _. Indeed, I did a quick (successful) experiment with the Win32 `SetWindowsHookEx()` API, _but I had to implement most of it in juce\_win32\_Windowing.cpp_ out of necessity, and that’s just for Windows.

Am I missing a simpler workaround? Surely it shouldn’t be possible for plugins _hosted inside a JUCE app_ to break JUCE keyboard/command functionality like this, and if not, I’d really appreciate a prompt fix!

Many thanks,  
Ben

---

<div class="post-metadata">

**Author:** ![benstaton](https://avatars.discourse-cdn.com/v4/letter/b/9fc29f/32.png) [@benstaton](https://forum.juce.com/u/benstaton)\
**Post date:** [September 20, 2022, 8:28am UTC](https://forum.juce.com/t/not-possible-to-intercept-keystrokes-when-hosting-some-plugins/52913/2 "2022-09-20T08:28:35Z")

</div>

Bumping this, as I still think it’s something that JUCE should handle. Thanks!