wpf: fix a handful of issues with the wpf control#6983
Merged
7 commits merged intomasterfrom Jul 20, 2020
Merged
Conversation
ghost
added
Area-WPFControl
DHowett
changed the title
zadjii-msft
approved these changes
Jul 20, 2020
We were not listening for WM_SYSKEY{UP,DOWN}
carlos-zamora
approved these changes
Jul 20, 2020
Member
carlos-zamora
left a comment
carlos-zamora
left a comment
There was a problem hiding this comment.
So glad you caught the font weight change hahaha
Member
Author
|
@msftbot merge this in 1 minute |
ghost
added
the
AutoMerge
|
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". |
ghost
merged commit
DHowett
added a commit
that referenced
this pull request
Jul 20, 2020
* 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)
DHowett
added a commit
that referenced
this pull request
Jul 20, 2020
* 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)
This pull request was closed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
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.