Windows: Update handling of system keypresses#2445
Windows: Update handling of system keypresses#2445msiglreith merged 1 commit intorust-windowing:masterfrom ajtribick:alt-space-fix
Conversation
msiglreith
left a comment
There was a problem hiding this comment.
thanks! a few changes would be needed
| } | ||
| 0 | ||
|
|
||
| if msg == WM_SYSCHAR { |
There was a problem hiding this comment.
I would prefer to completely remove the WM_SYSCHAR as a case we explicitly handle in WM_CHAR | WM_SYSCHAR - otherwise we would generate ReceivedCharacter events which isn't desired imo.
WM_SYSCHAR would be then handled by the default fallback.
There was a problem hiding this comment.
Good point. I've also added a handler for WM_MENUCHAR to disable the annoying beep sound when an ALT+keypress is entered. This could in principle be used to communicate an event to be used in a menu system, but not sure how generalisable that would be to other platforms.
- Pass WM_SYSKEYDOWN to DefWindowProc - Avoid intercepting WM_SYSCHAR to allow ALT+Space to work: removes ReceivedCharacter events for alt+keypress - Intercept WM_MENUCHAR to disable bell sound
|
Force pushed to pick up the CI fix |
- Pass WM_SYSKEYDOWN to DefWindowProc - Avoid intercepting WM_SYSCHAR to allow ALT+Space to work: removes ReceivedCharacter events for alt+keypress - Intercept WM_MENUCHAR to disable bell sound
- Pass WM_SYSKEYDOWN to DefWindowProc - Avoid intercepting WM_SYSCHAR to allow ALT+Space to work: removes ReceivedCharacter events for alt+keypress - Intercept WM_MENUCHAR to disable bell sound
|
This change broke compatibility between Windows and other platforms. Here is a relevant bug for Alacritty, for example: alacritty/alacritty#6356 Should I open a separate issue for this discussion, or should we use this one? |
|
Please open a new issue, thanks! |
CHANGELOG.mdif knowledge of this change could be valuable to usersThis follows Microsoft's documentation on handling the
WM_SYSCHARandWM_SYSKEYDOWNevents. Allows the ALT+Space menu to work.This also allows opening the window menu in fullscreen, as tested in the "fullscreen" example. I'm not sure whether or not that is desired behavior.
Resolves #2406