【发布时间】：2014-12-13 17:16:11
【问题描述】：
我是基于控制台的服务器软件的开发人员，在按下 Enter 之前，它有时似乎会锁定输入。我怀疑这是 System.Console 窗口中的 XOFF/XON（Ctrl-S/Ctrl-Q 流控制）处理。
是否可以（使用 .NET 调用或 Win32 API 函数）在使用 System.Console 进行输出和输入命令的 C#/.NET 应用程序中禁用 XOFF/XON 流控制处理？ （这也会影响其他系统控制台，例如 CMD.EXE 窗口，但我不关心这些情况。）我的应用程序是服务器软件；永远不要想要冻结控制台的键，尤其是可能会意外触发的键。
不知何故，我相信我的服务器应用程序的控制台在输入时获得了 Ctrl-S，或者可能认为在输入 S 时按下了 Ctrl 限定符。控制台锁定，直到我按 Enter 键。 （我认为 Ctrl-Q 也会发布它，但还没有另一个机会来测试它。）
我的进程是 .NET 上的 C# 服务器，这些是在运行 Windows Server 的 Hyper-V VM 上使用 System.Console.ReadLine() 的控制台。
这可能是导致问题的关键：我正在通过远程桌面 (RDP) 连接到 Hyper-V 主机。一种想法是 RDP 断开连接丢失了一个 Ctrl 键，然后输入的下一个“S”（通过我们的命令自动化软件）锁定终端。我们最终将用基于网络的命令输入替换它，但与此同时，我们正在解决这个问题，这需要工作人员手动干预才能让服务器再次运行。
更多信息：我尝试了以下操作，以防平板电脑的 RDP 会话触发快速编辑模式，但这并没有阻止锁定：
GetConsoleMode(handle, out oldmode);
int newmode = oldmode;
newmode |= ENABLE_EXTENDED_FLAGS; // required to disable the next two
newmode &= ~ENABLE_QUICK_EDIT_MODE; // force this OFF
newmode &= ~ENABLE_MOUSE_INPUT; // force this OFF
newmode &= ~ENABLE_WINDOW_INPUT; // force this OFF
newmode |= ENABLE_INSERT_MODE; // force this ON
if (newmode != oldmode)
{
SetConsoleMode(handle, newmode);
【问题讨论】：
-
我是在 Stack Overflow 上发帖的新手，但也许有人可以解释为什么有人会否决这个问题。对于 Stack Overflow 来说似乎很理想，因为这是一个与操作系统交互的编码软件问题，对于使用 System.Console（或系统控制台）的服务器软件来说，这是一个重大问题，Stack Overflow 似乎没有涵盖这一点或谷歌上的任何地方。 （我在发帖前找了几个小时。）我问：有人知道完成这个操作的 Win32 API 吗？
-
在 Linux 控制台上，这可以通过：“stty -ixon”来完成。除了实际的串行端口外，似乎没有等效的 Windows API。在 Windows 下始终启用它似乎是硬编码的，这对于服务器或实时应用程序来说是一种非常糟糕的情况。
-
您应该修正标题，以表明您正在尝试更改您自己的应用程序的行为，该应用程序使用 CONSOLE 子系统。现在听起来你正试图影响内置程序。
-
在 MSDN、StackOverflow 甚至 Google 搜索中似乎什么都没有，所以我知道我可能问的是“错误的问题”。也许我不需要禁用 XON/XOFF 流量控制；我只是不希望 WriteLine 阻止输出到普通控制台窗口，只是因为有人按下了 Ctrl-S 或其他东西。我不确定这是怎么发生的，除了我们的几个控制台每周都会遇到这个问题，直到工作人员连接并点击 Enter。如果有人除了重写我自己的控制台类之外有任何开箱即用的替代方案，我愿意接受建议。
-
是的，这非常令人惊讶。在我自己尝试之前，我几乎确信你疯了，而且这是一个 shell 函数，而不是 CSRSS.exe（控制台子系统）的一部分。想要禁用或拦截这些是非常合理的事情。我想您已经测试过在使用这些组合时是否会收到控制台控制处理程序回调（原因不明）？您是否也尝试过其他控制台模式标志？
标签： c# .net windows remote-desktop windows-console