Open mbatson opened 4 months ago
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.
EDIT: This issue seems to have been resolved on the
new_core
branch. See https://github.com/boppreh/keyboard/issues/635#issuecomment-1959107402keyboard 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 withread_event
,read_key
, andon_press_key
functions.The culprit seems to be the callback function passed to
hook
:https://github.com/boppreh/keyboard/blob/d232de09bda50ecb5211ebcc59b85bc6da6aaa24/keyboard/__init__.py#L1069
specifically the part,
or e.event_type == KEY_DOWN
. IfKEY_DOWN
is changed toKEY_UP
(as inon_press_key
), then the next key or key-chord (e.g.,a
orctrl+h
) is suppressed correctly (obviously, however, this breaksread_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 onKEY_DOWN
in order to function correctly, and can't be forced to always returnFalse
. I'm only a novice programmer though, so happy for someone to correct me on that if I'm wrong.