Fix #8930: [Win32] Don't handle printable keys on keydown if an edit box is in focus. #8976
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation / Problem
On Windows, printable input for text input is handled by WM_CHAR messages.
The WM_KEYDOWN handler tries to predict if a keydown will be followed by WM_CHAR message to do the right thing, but this prediction can fail if IMEs are in play. This can lead to duplicate text input.
Description
If a key press is in fact printable text, it will result in a WM_CHAR (or a WM_IME_*) message. If no WM_CHAR follows, it is not printable text. As such, handle printable input only on the WM_CHAR message. Without an edit box, do the handling in keydown as usual to support hotkeys.
Limitations
I only tested normal German/latin input and the japanese IME. Some other IMEs or strange keyboard layouts might behave differently.
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.