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

WT programs do not respond to arrow keys sent from the SendKeys API #7843

Closed
outlandishwherewolf843 opened this issue Oct 7, 2020 · 6 comments · Fixed by #7900
Closed

WT programs do not respond to arrow keys sent from the SendKeys API #7843

outlandishwherewolf843 opened this issue Oct 7, 2020 · 6 comments · Fixed by #7900
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@outlandishwherewolf843
Copy link

Environment

Windows build number: 10.0.18362.0
Windows Terminal version 1.3.2651.0:

Any other software?

A C# program using the SendKeys API

Steps to reproduce

Write a program in C# using the SendKeys API to emulate keypresses. Use this program to attempt to send arrow keys to a program running in Windows Terminal.

Expected behavior

The program in Windows Terminal should respond as if an arrow key has been pressed. In Powershell or CMD or most shells, the cursor should move according to the arrow key that is pressed.

Actual behavior

The cursor blinks as if a key has been pressed, but will not move. The program in WT does not respond in any other way. The up and down arrow keys sent by SendKeys WILL work in the dropdown menu however. It seems like programs running in WT will respond to most other keys appropriately.

@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 Oct 7, 2020
@zadjii-msft
Copy link
Member

Do you happen to know if SendKeys sends the key events with the scan code set to 0? I bet we're filtering them out, because they have a 0 scancode.

There's also #7438 and #7495 that I'm guessing are all the same root cause.

/cc @lhecker

@zadjii-msft zadjii-msft added Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. labels Oct 7, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Oct 7, 2020
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Oct 7, 2020
@DHowett DHowett removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Oct 9, 2020
@outlandishwherewolf843
Copy link
Author

I don't know enough to be able to say. Sounds like a good hypothesis though. Is there an easy way to find out?

@lhecker
Copy link
Member

lhecker commented Oct 10, 2020

It most certainly is the underlying reason. Currently all "improper" SendInput inputs are ignored, whose wVk are invalid (outside of the 0x01-0xff range), or whose wScan is zero. See here.
To be completely honest: When I submitted the offending PR, I didn't think of testing whether AutoHotkey and PowerTools still work with non-character key events. 😟

Optimally AutoHotkey, PowerTools, etc. should fix their SendInput code and only send valid wVk and wScan values. But since we should strive to be as compatible as possible to "incorrect" software, I'll try to look into this in the coming days. @zadjii-msft 🙂

@lhecker
Copy link
Member

lhecker commented Oct 10, 2020

Oh and just for reference... This is a minimal example of how you use SendInput correctly:

#define NOMINMAX
#include <Windows.h>
#include <cstdio>

int main()
{
    printf("Waiting 5 seconds for you to switch to Windows Terminal...\n");
    Sleep(5000);
    printf("Sending arrow up key\n");

    INPUT ip{};
    ip.type = INPUT_KEYBOARD;
    ip.ki.wVk = VK_UP;
    ip.ki.wScan = LOWORD(MapVirtualKeyW(VK_UP, MAPVK_VK_TO_VSC));

    ip.ki.dwFlags = 0;
    SendInput(1, &ip, sizeof(INPUT));

    ip.ki.dwFlags = KEYEVENTF_KEYUP;
    SendInput(1, &ip, sizeof(INPUT));

    return 0;
}

(This example is only correct in the scope of the problem in this issue though.)

@ghost ghost added the In-PR This issue has a related PR label Oct 12, 2020
@ghost ghost closed this as completed in #7900 Oct 27, 2020
ghost pushed a commit that referenced this issue Oct 27, 2020
While not explicitly permitted, a wide range of software (including
Windows' own touch keyboard) sets the `wScan` member of the `KEYBDINPUT`
structure to 0, resulting in `scanCode` being 0 as well.  In these
situations we'll now use the `vkey` to get a `scanCode`.

Validation
----------
* AutoHotkey
  * Use a keyboard layout with `AltGr` key
  * Execute the following script:
    ```ahk
    #NoEnv
    #Warn
    SendMode Input
    SetWorkingDir %A_ScriptDir%
    <^>!8::SendInput {Raw}»
    ```
  * Press `AltGr+8` while the Terminal is in the foreground
  * Ensure » is being echoed ✔️
* PowerToys
  * Add a `Ctrl+I -> ↑ (up arrow)` keyboard shortcut
  * Press `Ctrl+I` while the Terminal is in the foreground
  * Ensure the shell history is being navigated backwards ✔️
* Windows Touch Keyboard
  * Right-click or tap and hold the taskbar and select "Show touch
    keyboard" button
  * Open touch keyboard
  * Ensure keyboard works like a regular keyboard ✔️
  * Ensure unicode characters are echoed on the Terminal as well (except
    for Emojis) ✔️

Closes #7438
Closes #7495
Closes #7843
@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 Oct 27, 2020
DHowett pushed a commit that referenced this issue Oct 28, 2020
While not explicitly permitted, a wide range of software (including
Windows' own touch keyboard) sets the `wScan` member of the `KEYBDINPUT`
structure to 0, resulting in `scanCode` being 0 as well.  In these
situations we'll now use the `vkey` to get a `scanCode`.

Validation
----------
* AutoHotkey
  * Use a keyboard layout with `AltGr` key
  * Execute the following script:
    ```ahk
    #NoEnv
    #Warn
    SendMode Input
    SetWorkingDir %A_ScriptDir%
    <^>!8::SendInput {Raw}»
    ```
  * Press `AltGr+8` while the Terminal is in the foreground
  * Ensure » is being echoed ✔️
* PowerToys
  * Add a `Ctrl+I -> ↑ (up arrow)` keyboard shortcut
  * Press `Ctrl+I` while the Terminal is in the foreground
  * Ensure the shell history is being navigated backwards ✔️
* Windows Touch Keyboard
  * Right-click or tap and hold the taskbar and select "Show touch
    keyboard" button
  * Open touch keyboard
  * Ensure keyboard works like a regular keyboard ✔️
  * Ensure unicode characters are echoed on the Terminal as well (except
    for Emojis) ✔️

Closes #7438
Closes #7495
Closes #7843

(cherry picked from commit d51d8dc)
@ghost
Copy link

ghost commented Nov 11, 2020

🎉This issue was addressed in #7900, which has now been successfully released as Windows Terminal v1.4.3141.0.:tada:

Handy links:

@ghost
Copy link

ghost commented Nov 11, 2020

🎉This issue was addressed in #7900, which has now been successfully released as Windows Terminal Preview v1.5.3142.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.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) 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.

4 participants