Skip to content
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

Further refine ToUnicodeEx calls in CharacterFromKeyEvent #3554

Closed
miniksa opened this issue Nov 13, 2019 · 2 comments · Fixed by #4192
Closed

Further refine ToUnicodeEx calls in CharacterFromKeyEvent #3554

miniksa opened this issue Nov 13, 2019 · 2 comments · Fixed by #4192
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@miniksa
Copy link
Member

miniksa commented Nov 13, 2019

To fix the latter tangential issue, I'd like to propose that we simply return the first character of the output buffer, if the return value of ToUnicodeEx is >1. What do you think? (I'd open a seperate PR for this.)

That sounds reasonable based on the analysis above.

Originally posted by @miniksa in #3117 (comment)

This represents fixing the issue described in #3117 where other forms of multiple copies can occur based on the responses from ToUnicodeEx.

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Nov 13, 2019
@miniksa miniksa added Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. labels Nov 13, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Nov 13, 2019
@miniksa
Copy link
Member Author

miniksa commented Nov 13, 2019

@lhecker, here's the follow on.

@miniksa miniksa removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Nov 13, 2019
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Nov 13, 2019
@ghost ghost added the In-PR This issue has a related PR label Apr 7, 2020
@ghost ghost closed this as completed in #4192 Apr 7, 2020
ghost pushed a commit that referenced this issue Apr 7, 2020
My basic idea was that `WM_CHAR` is just the better `WM_KEYDOWN`.
The latter fails to properly support common dead key sequences like in
#3516.

As such I added some logic to `Terminal::SendKeyEvent` to make it return
false if the pressed key represents a printable character.
This causes us to receive a character event with a (hopefully) correctly
composed code unit, which then gets sent to `Terminal::SendCharEvent`.
`Terminal::SendCharEvent` in turn had to be modified to support
potentially pressed modifier keys, since `Terminal::SendKeyEvent` isn't
doing that for us anymore.
Lastly `TerminalInput` had to be modified heavily to support character
events with modifier key states. In order to do so I merged its
`HandleKey` and `HandleChar` methods into a single one, that now handles
both cases.
Since key events will now contain character data and character events
key codes the decision logic in `TerminalInput::HandleKey` had to be
rewritten.

## PR Checklist
* [x] CLA signed
* [x] Tests added/passed
* [x] I've discussed this with core contributors already.

## Validation Steps Performed

* See #3516.
* I don't have any keyboard that generates surrogate characters. Due to
  this I modified `TermControl::_SendPastedTextToConnection` to send the
  data to `_terminal->SendCharEvent()` instead. I then pasted the test
  string ""𐐌𐐜𐐬" and ensured that the new `TerminalInput::_SendChar`
  method still correctly assembles surrogate pairs.

Closes #3516
Closes #3554 (obsoleted by this PR)
Potentially impacts #391, which sounds like a duplicate of #3516
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Apr 7, 2020
@ghost
Copy link

ghost commented Apr 22, 2020

🎉This issue was addressed in #4192, which has now been successfully released as Windows Terminal Preview v0.11.1121.0.:tada:

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants