Keyboard events, DocumentWindow and the host

General JUCE discussion
1


Hello to everyone!


I'm working on a plugin that does not use it's own PluginEditor (AudioProcessorEditor) but uses a Common Editor, a separate JUCE DocumentWindow. All instances of this plugin uses this Common editor, the current editable instance is selectable inside it. (This common editor is created in the first plugin instance's constructor)

It works well, but i ran into a problem and i can't solve it. I'm testing my plugins in a host called "Console" and a strange thing happens. The active window (which has the focus) is my common editor DocumentWindow. I press a key (F3), i handle this key (juce_win32_Windowing::doKeyDown returns true) but Console starts one of its functions!!! (F3 in Console = turn on audio).


I don't understand it, how can this keyboard event get to Console when the active window is my Common Editor? My common editor is opened on the Desktop. (constructor 4th param is true) I've tried to open it with this code but it didn't help:

mainWindow->addToDesktop(mainWindow->getDesktopWindowStyleFlags(), (void *)GetDesktopWindow());

Can I solve it somehow to block the host getting any keyboard message when a DocumentWindow is the active window? Any suggestion?

Platform: Windows 8.1 64bit, Corei7 8GBRAM.
JUCE version: 3.0.8

Thanks,
Zajos
 

2

Hi,


Well, finally i figured it out. My JUCE dll and the host I mentioned(Console) are on the same thread. So the JUCE window I open from the dll is on this thread too. First I thought that every window in this thread got every keyboard message somehow, not just the active one. Its not true. It turned out that these keyboard events are hotkeys (WM_HOTKEY message) in the host and as I red that these were posted to the registred window allways, independently of the active window. 

What cna I do? 

1, I have a chance to create my editor window in a separate thread, but that isn't fine because JUCE has one global MessageManager and if I register it to the new thread then the AudioProcessor and the AudioEditor will fail. (My plugin has an AudioProcessorEditor and a main editor that I mentioned previousl.  In the main editor you can edit the interface of a child plugin) So new thread is not good.

2, Somehow I block the host's hot keys. Now I do this, I register a wm_hotkey (RegisterHotKey) to all specific keys in my JUCE application and then transfer these messages to a WW_KEYDOWN. In this case the host won't get these messages anymore.

Zajos