GlobalHookMode.FINAL

[luecking]

Hello,
I played around with it. But I run into problems.
Indeed, it stops forwarding the key events to other applications. But now all keys are blocked.

It would be better, if only keys which are registered, will be blocked for other applications.

I'm testing with Windows 10 and [Windows]+[G] for example.

Please have a look.

[kristian]

Hello @luecking, sorry for the late reply.

There are two ways to be doing this. One is unfortunately not so easy to do, with the current design of the library, the other is much more less elgant:

Option A: Would be that every event (similar to e.g. events in JavaScript) get a "preventDefault" method. That way you would be able to call the method in your handler, which would prevent forwarding the message to further hooks. That way you could for each event decide, if you want to forward it or not. In the design of this library, it was crucial to not block the input event handling, as otherwise inputs might be lost. Thus the decision was made to store every event in an inputBuffer instead, continue processing the native input event, while another Java thread processes the inputBuffer. This means, also regardless of "how long" the processing of your eventhandler takes, no inputs will be skipped. This also means, when your event handler is called, the input processing is already processing the next hook, so to implement a "preventDefault" method, would require a redesign of big parts of this library.

Option B: Currently every keystroke is captured by the library and forwarded to your handler. This is also the way the low-level system hook is inteded to be used natively. There is no way of just capturing events of single keys. Rather you ignore the input events you are not interested in. This means also my library does not know what keys you are actually interested in, so "what keys you registered". When it comes to the "FINAL" setting, one could add a new "key map" that defines the keys for which the events should NOT be forwarded. This adds another level of complexity: which keys should be forwarded and which keys shouldn't? In your example you said you don't want to forward [Windows] + [G]. Both are separate input events. This means, what to do? Blocking all [Windows] key event inputs is not desired. You would have to first block the [Windows] key fowarding, and if any other key than [G] is pressed, re-fire the forwarding, which is not possible using these low-level hook methods!

In short: I am not completely satisfied with both solutions, which is why I would like to put this issue on "inactive" for now. Please feel free to come up with any better idea or submit a pull request.

Sorry, hope this helps anyways. Thanks & regards, Kristian