Blocking RawInput Event

[Fjolnir-Dvorak]

The selected compose key is not longer avaiable as RawInput Event through WinApi. I can give no further debug information with the tools I use because there is simply no event I am able to catch when pressing the virtual compose key.

[samhocevar]

Yeah, it is a design decision that WinCompose “owns” the compose key and tries to hide it from other apps and from the rest of the input hook chain.

Can you explain the specific use case that needs fixing? There are probably acceptable workarounds. I may, for instance, allow for WinCompose to disable itself if a list of explicit application names or window classes has focus.

[Fjolnir-Dvorak]

I am still researching how exactly to block keys and if there is a way around.

The usecase: I have a second (and a third, etc...) keyboard configured as a macro-keyboard intercepting the inputs with rawInput and system wide keyhooks dropping the key event if it arrives from a special device.

I expected that is was intended to drop the key instead removing only the virtualkey until I set the compose key to RMENU. If I press RMENU with AE it will write a€ which confused me because the € is only a virtual key. If this program is supposed to swallow the key than I suppose that My assumtion is based on a bug handling the RMENU key as compose key.

But I am wondering still: What is the purpose of "stealing" the key from everyone except windows instead of only dropping the virtual key.

And Thank you for the quick response :D

[Fjolnir-Dvorak]

Thinking about that problem: would it be a nice idea to be able to select whether the compose key should be active on all keyboards or only on a single one? I will look further into it. If You are not interested in this setting I still can change it locally and upload it back to github so you can look into it if you want to.

[samhocevar]

Sounds like an acceptable feature to me. I would frown upon features that cannot be easily tested, but plugging a second keyboard doesn’t seem to cumbersome, so I’ll happily test any changes you’d like to suggest.

[Fjolnir-Dvorak]

Hmm, there is one big problem: It is not possible to determine the device which send that key stroke. The only sollution I can see at the moment to solve this problem / add that as a feature is to use the Interception Interface/Driver to be able to get the device information. That would require a full rewrite of the intern hooking system to use interception instead of WinApi... Ans it will require root access to install (to install the signed driver)