suppress=True doesn't work with read_hotkey and on_release_key
mbatson opened this issue · 1 comments
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
:
Line 1069 in d232de0
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.
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.