suppress=True doesn't work with read_hotkey and on_release_key

[mbatson]

EDIT: This issue seems to have been resolved on the new_core branch. See #635 (comment)

keyboard version: 0.13.5
OS: Windows 10 Pro 22H2

When calling read_hotkey(suppress=True), the next key or key-chord is not being suppressed and is passing through to whatever window is active.
The hotkey is still being read by the function correctly, just that the suppression of the key to the rest of the OS is not functioning.

suppress=True is working correctly with read_event, read_key, and on_press_key functions.

The culprit seems to be the callback function passed to hook:

keyboard/keyboard/__init__.py

Line 1069 in d232de0

fn = lambda e: queue.put(e) or e.event_type == KEY_DOWN

specifically the part, or e.event_type == KEY_DOWN.
If KEY_DOWN is changed to KEY_UP (as in on_press_key), then the next key or key-chord (e.g., a or ctrl+h) is suppressed correctly (obviously, however, this breaks read_hotkey, preventing it from recording key-chords, and so isn't actually a solution).

This issue could possibly be related to #596? Unfortunately, the workaround given in #596 doesn't seem possible with read_hotkey, as its callback needs to return the conditional check on KEY_DOWN in order to function correctly, and can't be forced to always return False. I'm only a novice programmer though, so happy for someone to correct me on that if I'm wrong.

[mbatson]

After some more digging I realised that there's an open issue addressing the buggy implementation of key suppression (#22), and that a rewrite of the suppression system is underway in the new_core branch. I've given read_hotkey(suppress=True) a quick test on new_core on Windows 10, and this issue seems to be fixed there and the suppression behaviour working as expected.

As new_core hasn't yet been merged into master I'll leave this issue open for now just so it's more visible for any user encountering the same problem, but I'm happy for it to be closed by maintainer whenever desired.