Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Key presses with unset scancode get lost #1623

Closed
rokups opened this issue Jan 13, 2020 · 2 comments
Closed

Key presses with unset scancode get lost #1623

rokups opened this issue Jan 13, 2020 · 2 comments
Assignees
@elmindreda
Labels
bug Bug reports and bugfix pull requests input Keyboard, joystick or mouse verified Reproduced or otherwise verified bugs Windows Win32 specific (not Cygwin or WSL)
Milestone
3.3.2

Comments

@rokups
Copy link
Contributor

rokups commented Jan 13, 2020

Windows clipboard (Win+v) sends windows messages for CTRL+v with no scancode set. GLFW still catches CTRL press, but only because it has special case handling based on keycode. V press is lost because scancode is used to translate key press to gflw key.
@rokups rokups mentioned this issue Jan 13, 2020
Closed
@elmindreda elmindreda self-assigned this Jan 15, 2020
@elmindreda elmindreda added bug Bug reports and bugfix pull requests Windows Win32 specific (not Cygwin or WSL) input Keyboard, joystick or mouse verified Reproduced or otherwise verified bugs labels Jan 15, 2020
@elmindreda elmindreda added this to the 3.3.2 milestone Jan 15, 2020
@elmindreda elmindreda changed the title [WIN32] Key presses with unset scancode get lost Key presses with unset scancode get lost Jan 15, 2020
elmindreda added a commit that referenced this issue Jan 15, 2020
@elmindreda
Win32: Fix scancode when key message only had VK
ed30a82 
Some synthetic key messages come with a scancode of zero, causing them
to be translate to GLFW_KEY_UNKNOWN.  This fills in the missing scancode
by translating the provided virtual key.

Rather than further complicate a single-use function, its body is merged
into the key message handler.

Fixes #1623.
@elmindreda
Copy link
Member

Thank you for reporting this! If possible, please test if the win32-key-scancode-fixes branch resolves this.

@rokups
Copy link
Contributor Author

rokups commented Jan 16, 2020

This issue is also fixed. Thank you very much!

elmindreda added a commit that referenced this issue Jan 16, 2020
@elmindreda
Win32: Fix scancode when key message only had VK
51ea8af 
Some synthetic key messages come with a scancode of zero, causing them
to be translate to GLFW_KEY_UNKNOWN.  This fills in the missing scancode
by translating the provided virtual key.

Rather than further complicate a single-use function, its body is merged
into the key message handler.

Fixes #1623.
elmindreda added a commit that referenced this issue Jan 17, 2020
@elmindreda
Win32: Fix scancode when key message only had VK
e535380 
Some synthetic key messages come with a scancode of zero, causing them
to be translate to GLFW_KEY_UNKNOWN.  This fills in the missing scancode
by translating the provided virtual key.

Rather than further complicate a single-use function, its body is merged
into the key message handler.

Fixes #1623.

(cherry picked from commit 789a2bc)
m4ce-w1ndu pushed a commit to m4ce-w1ndu/glfw that referenced this issue Jul 23, 2022
@elmindreda
Win32: Fix scancode when key message only had VK
76b647d 
Some synthetic key messages come with a scancode of zero, causing them
to be translate to GLFW_KEY_UNKNOWN.  This fills in the missing scancode
by translating the provided virtual key.

Rather than further complicate a single-use function, its body is merged
into the key message handler.

Fixes glfw#1623.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@elmindreda elmindreda

Labels
bug Bug reports and bugfix pull requests input Keyboard, joystick or mouse verified Reproduced or otherwise verified bugs Windows Win32 specific (not Cygwin or WSL)
Projects
None yet
Milestone
3.3.2
Development

No branches or pull requests
2 participants
@elmindreda @rokups