Skip to content

Fix Windows ALT codes (#15938, #18159) #18612

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.

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

Closed

Conversation

mgarstenauer
Copy link
Contributor

What does the pull request do?

This PR fixes ALT codes for Windows.

What is the current behavior?

On Windows, ALT codes can be entered by holding ALT and entering a number on the numpad. For example: ALT+5 produces '♣'. This behavior is currently broken:

  • The wrong ALT codes are produced. For example, ALT+5 produces '7' (ALT+55) instead of '♣'.
  • Pressing the ALT code really quickly may sometimes produce the right ALT code.
  • The resulting character does not appear when entered after pressing an arrow key (or other navigation key).
  • ALT in combination with arrow keys insert unexpected symbols. For example, pressing ALT+↓ produces the ALT code for ALT+22.

What is the updated/expected behavior with this PR?

ALT codes are now produced correctly and no longer swallowed.
Other ALT combinations (non-numpad keys) no longer produce ALT codes.

Tested on: Windows 11 Pro (Version 24H2, OS build 26100.3476)

I have tested ALT codes with English (US) and German keyboard layouts:

✅ ALT codes are produced correctly.
✅ German AltGr combinations continue to work as expected.
✅ IME (such as Japanese characters) continues to work as expected.

How was the solution implemented (if it's not obvious)?

The main changes:

  • Calling TranslateMessage while entering an ALT code seems to mess up the keyboard input.
  • _ignoreWmChar needs to be reset, otherwise it can swallow input.

Checklist

Breaking changes

Obsoletions / Deprecations

Fixed issues

Fixes #15938
Fixes #18159

@mgarstenauer
Copy link
Contributor Author

Note that I am not a Win32 or IME expert. Hope the changes make sense.

Let me know if I need to add anything (tests?).

@cla-avalonia
Copy link
Collaborator

cla-avalonia commented Apr 8, 2025

  • All contributors have signed the CLA.

@mgarstenauer
Copy link
Contributor Author

@cla-avalonia agree

@MrJul
Copy link
Member

MrJul commented Apr 10, 2025

Thank you for your contribution!

Unfortunately, I don't think we should be handling Alt codes manually. I've dug into the problem, and this happens because Avalonia calls ToUnicodeEx for WM_SYSKEYDOWN, which messes up the keyboard state.

I've opened an alternative PR #18624, so I'm going to close this one.

@MrJul MrJul closed this Apr 10, 2025
@mgarstenauer
Copy link
Contributor Author

@MrJul Ah, that explains the problem. Thanks for investigating and fixing.

@mgarstenauer mgarstenauer deleted the fix-windows-alt-codes branch April 10, 2025 12:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Alt+Up in TextBox adds an X character Alt codes do not produce expected characters
4 participants