-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
wpf: fix a handful of issues with the wpf control #6983
Conversation
We were not listening for WM_SYSKEY{UP,DOWN}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So glad you caught the font weight change hahaha
@msftbot merge this in 1 minute |
Hello @DHowett! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
* send alt/F10 through the control We were not listening for WM_SYSKEY{UP,DOWN} * extract the actual scancode during WM_CHAR, not the bitfield We were accidentally sending some of the additional keypress data in with the character event in Win32 Input Mode * set default fg/bg to campbell The WPF control starts up in PowerShell blue even though it's not typically used in PowerShell blue. * don't rely on the font to determine wideness This is a cross-port of #2928 to the WPF control * deterministic shutdown In testing, I saw a handful of crashes on teardown because we were not shutting down the render thread properly. * don't pass 10 for the font weight ... When Cascadia Code is set, it just looks silly. * trigger render when selection is cleared, do it under lock Fixes #6966. (cherry picked from commit 76de2ae)
* send alt/F10 through the control We were not listening for WM_SYSKEY{UP,DOWN} * extract the actual scancode during WM_CHAR, not the bitfield We were accidentally sending some of the additional keypress data in with the character event in Win32 Input Mode * set default fg/bg to campbell The WPF control starts up in PowerShell blue even though it's not typically used in PowerShell blue. * don't rely on the font to determine wideness This is a cross-port of #2928 to the WPF control * deterministic shutdown In testing, I saw a handful of crashes on teardown because we were not shutting down the render thread properly. * don't pass 10 for the font weight ... When Cascadia Code is set, it just looks silly. * trigger render when selection is cleared, do it under lock Fixes #6966. (cherry picked from commit 76de2ae)
We were not listening for WM_SYSKEY{UP,DOWN}
We were accidentally sending some of the additional keypress data in with
the character event in Win32 Input Mode
The WPF control starts up in PowerShell blue even though it's not typically used
in PowerShell blue.
This is a cross-port of TermControl: force all ambiguous glyphs to be narrow #2928 to the WPF control
In testing, I saw a handful of crashes on teardown because we were not shutting
down the render thread properly.
When Cascadia Code is set, it just looks silly.
Fixes #6966.