01-02-2019, 11:50 AM
Thanks for reporting this and putting in some good work for a nice bug report.
Like you, this issue only happens for me in Windows 7. Given that it only affects this older OS in very specific situations and that our keypress handler code path is so simple, unfortunately I don't think we can fix it or attempt to find a workaround for it.
On Windows, to create a keypress handler, we simply call the SetWindowsHookEx() function to register a hook function. The hook function simply gets the KBDLLHOOKSTRUCT object, checks the flags to make sure they do not contain LLKHF_INJECTED, LLKHF_ALTDOWN, or LLKHF_UP, gets the registered hdi_core callback for the key code from a map lookup (very fast), then executes the callback. If any of the above actions fail, we call the CallNextHookEx() function.
In any event, that's all very standard and simple stuff for Windows keypress handling, so I'm not sure where the fault could be on our end of things.
Like you, this issue only happens for me in Windows 7. Given that it only affects this older OS in very specific situations and that our keypress handler code path is so simple, unfortunately I don't think we can fix it or attempt to find a workaround for it.
On Windows, to create a keypress handler, we simply call the SetWindowsHookEx() function to register a hook function. The hook function simply gets the KBDLLHOOKSTRUCT object, checks the flags to make sure they do not contain LLKHF_INJECTED, LLKHF_ALTDOWN, or LLKHF_UP, gets the registered hdi_core callback for the key code from a map lookup (very fast), then executes the callback. If any of the above actions fail, we call the CallNextHookEx() function.
In any event, that's all very standard and simple stuff for Windows keypress handling, so I'm not sure where the fault could be on our end of things.