Repository navigation
Closed
Labels
Area-InputRelated to input processing (key presses, mouse, etc.)Related to input processing (key presses, mouse, etc.)Area-VTVirtual Terminal sequence supportVirtual Terminal sequence supportIssue-BugIt either shouldn't be doing this or needs an investigation.It either shouldn't be doing this or needs an investigation.Product-TerminalThe new Windows Terminal.The new Windows Terminal.Resolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Description
Something wrong with keyboard modifiers processing?
We have wrong processing of keyboard input with modifiers... For example:
using System;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
ConsoleKeyInfo cki;
do
{
cki = Console.ReadKey();
Console.Write(" --- You pressed ");
if ((cki.Modifiers & ConsoleModifiers.Alt) != 0)
{
Console.Write("ALT+");
}
if ((cki.Modifiers & ConsoleModifiers.Shift) != 0)
{
Console.Write("SHIFT+");
}
if ((cki.Modifiers & ConsoleModifiers.Control) != 0)
{
Console.Write("CTL+");
}
Console.WriteLine(cki.Key.ToString());
}
while (cki.Key != ConsoleKey.Escape);
}
}
}Same keys sequence is pressed... 1 2 ... 0 RCtrl+1 RCtrl+2 RCtrl+3... RCtrl+0
LCtrl+1 LCtrl+2 LCtrl+3 LCtrl+4
We have some, but also wrong result only for Ctrl+2... Shift modifier added.
Same behaviour also with more complicated software - "Far Manager" for example (in this situation problem not with simple Console.ReadKey but with keyboard events processing. In this example we don't see any reactions of software on pressing Ctrl like we can see in old console. So problems also with keyboard modifiers).
Metadata
Metadata
Assignees
Labels
Area-InputRelated to input processing (key presses, mouse, etc.)Related to input processing (key presses, mouse, etc.)Area-VTVirtual Terminal sequence supportVirtual Terminal sequence supportIssue-BugIt either shouldn't be doing this or needs an investigation.It either shouldn't be doing this or needs an investigation.Product-TerminalThe new Windows Terminal.The new Windows Terminal.Resolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.Fix is checked in, but it might be 3-4 weeks until a release.

Activity
DarthJahus commentedon Jul 1, 2019
I've got an issue with this. When I press
ALTGR+àto write @ on French layout keyboard, it writesà. This makes it unusable with a French keyboard.Also, looks like a duplicate of #521
DHowett-MSFT commentedon Jul 2, 2019
Jahus (@DarthJahus) that is the unrelated issue #521, which is fixed and will be released eventually.
j4james commentedon Nov 12, 2019
There are a combination of issues here. First off, we don't correctly support the VT sequences for the number characters when combined with
Ctrl. OnlyCtrl+2works, and even then it's only on certain keyboards. This is discussed in issue #3507.The bigger problem is that the standard VT sequences for transmitting keypresses are limited in what they can represent. So even if we were handling these keys perfectly, there's no difference between the left and right
Ctrlkeys, and something likeCtrl+2should show up as the same key asCtrl+SPACEandCtrl+@(which on a US keyboard isCtrl+Shift+2). Potential solutions for this are discussed in issue #879.Add support for win32-input-mode to conhost, ConPTY, Terminal (#6309)
Update Fork (#1)