Windows: Pass EventStatus::Ignored keyboard events to parent (feature parity with OSX)

[AlexCharlton]

Title says it all, I think :)

[micahrj]

This is not going to work correctly when there is not a one-to-one relationship between window messages and baseview keyboard events. The process_message call immediately above these changes can collect up multiple window messages which correspond to a single logical keyboard event (e.g. in the case of dead keys in some keyboard layouts). When this happens, the effect of this PR will be that all but the final window message will always be forwarded to the parent, and only the final message will be optionally forwarded or not forwarded depending on the returned EventStatus.

[AlexCharlton]

This is not going to work correctly when there is not a one-to-one relationship between window messages and baseview keyboard events. The process_message call immediately above these changes can collect up multiple window messages which correspond to a single logical keyboard event (e.g. in the case of dead keys in some keyboard layouts). When this happens, the effect of this PR will be that all but the final window message will always be forwarded to the parent, and only the final message will be optionally forwarded or not forwarded depending on the returned EventStatus.

Ah ha! I did not appreciate that process_message was doing this. I suppose a solution here could be to stash the set of (msg, wparam, lparam) used to generate an event in KeyboardState, return them with the event, and then SendMessageW the lot of them when the event is ignored. Sound workable?

[micahrj]

Ah ha! I did not appreciate that process_message was doing this. I suppose a solution here could be to stash the set of (msg, wparam, lparam) used to generate an event in KeyboardState, return them with the event, and then SendMessageW the lot of them when the event is ignored. Sound workable?

That sounds reasonable to me, though I would want to see some testing for the specific multi-message cases that process_message handles.

More generally, I would want to see some testing of this PR in different hosts to determine if and where it is actually necessary and if it actually has the desired effect.

[AlexCharlton]

More generally, I would want to see some testing of this PR in different hosts to determine if and where it is actually necessary and if it actually has the desired effect.

By "see some testing," I'm guessing you mean you'd like me to describe under what conditions I tried this out?

As for "if and where it is actually necessary", I'll refer you to the original commit+comment that introduced this feature: 72b6a4a#diff-14da7c350de5742eaa248de110fefeae9b4b639c0358e26024d6040ccf174a41R100-R105

There's lots of cases where this could be useful, though. Many plugins don't have any keybindings at all, so you really want to ignore everything or else you'll block your DAW's keybindings while your plugin is active. Or you could only handle keys that do something in your plugin, so that anything that doesn't overlap will still go through to your DAW.

[micahrj]

I definitely understand the rationale for the feature. I'm more interested in examples of specific hosts where this particular approach actually has the desired effect. Keyboard focus handling in hosts and plugins on Windows is a real mess, with hosts implementing all sorts of workarounds (using Win32 subclassing to intercept keyboard events received by the plugin's child window, filtering out keyboard events at the point of the event loop, etc.) and plugins implementing all sorts of workarounds in turn (creating invisible child windows to handle keyboard events, registering keyboard hooks, etc.). Because of that, it is not obvious to me just from looking at the code whether a change like this will actually accomplish what it's supposed to without causing other problems.