В какой-то момент истории мы сломали Ctrl+S, чтобы приостановить вывод в хосте консоли. Я думаю, что это было примерно в то время, когда мы возились с материалом ExtendedEditKeys.
У меня больше нет полного контекста по этому поводу, это просто еще одна ошибка в заголовке для заметок, которая у меня была как MSFT: 17790922, которую я переношу наружу.
Нам нужно повторно исследовать состояние паузы Ctrl+S на протяжении веков. Как v1 это сделал? Как v2 сделала это по сравнению с выпусками Windows 10? Нужно ли нам как-то повторно вводить его в качестве опции?
Ctrl+S / XOFF , Ctrl+Q XON. Это просто старое программное управление потоком. Говоря о себе, я бы использовал его довольно часто с потоковыми логами, кошкой, хвостом и т. Д. Остаток от старых телетайпов / терминалов, перенесенный в VT.
О, и да, мне кажется, вам определенно следует снова ввести его.
В NT 4 с включенным режимом линейного ввода вывод консоли можно было приостановить либо с помощью клавиши паузы ( VK_PAUSE
), либо с помощью Ctrl-S. Я уверен, что Ctrl-S был выбран для удобства людей, привыкших к терминалам. Тем не менее, нажатие любой клавиши возобновляет вывод; это не обязательно должно быть Ctrl-Q, так как консоль на самом деле не является терминалом, отвечающим на XOFF/XON.
Примерно в Windows 2000 был добавлен параметр реестра «ExtendedEditKey». Если бы это было включено, пользовательские ключи редактирования можно было бы определить в «ExtendedEditkeyCustom». Я не думаю, что это когда-либо было задокументировано. Если пользовательское сопоставление не было определено, использовалось сопоставление по умолчанию, включающее сопоставление Ctrl-S -> VK_PAUSE
. Таким образом, Ctrl-S по-прежнему работал по умолчанию, даже если «ExtendedEditKey» был включен.
Новая консоль предоставляет «ExtendedEditKey» в диалоговом окне свойств, но теперь она переназначена для «расширенных клавиш выбора текста». Поскольку «ExtendedEditkeyCustom», похоже, больше не реализуется за пределами рудиментарного макроса CONSOLE_REGISTRY_EXTENDEDEDITKEY_CUSTOM
в исходном коде, я думаю, что IsPauseKey
должен просто возвращать true для VK_PAUSE
или Ctrl-S, что восстановить исходное поведение.
В соответствующей заметке в источнике я вижу, что «ExtendedEditKey» и диалоговое окно свойств задают значение global g_fEditKeys
, но оно, похоже, не используется.
Самый полезный комментарий
В NT 4 с включенным режимом линейного ввода вывод консоли можно было приостановить либо с помощью клавиши паузы (
VK_PAUSE
), либо с помощью Ctrl-S. Я уверен, что Ctrl-S был выбран для удобства людей, привыкших к терминалам. Тем не менее, нажатие любой клавиши возобновляет вывод; это не обязательно должно быть Ctrl-Q, так как консоль на самом деле не является терминалом, отвечающим на XOFF/XON.Примерно в Windows 2000 был добавлен параметр реестра «ExtendedEditKey». Если бы это было включено, пользовательские ключи редактирования можно было бы определить в «ExtendedEditkeyCustom». Я не думаю, что это когда-либо было задокументировано. Если пользовательское сопоставление не было определено, использовалось сопоставление по умолчанию, включающее сопоставление Ctrl-S ->
VK_PAUSE
. Таким образом, Ctrl-S по-прежнему работал по умолчанию, даже если «ExtendedEditKey» был включен.Новая консоль предоставляет «ExtendedEditKey» в диалоговом окне свойств, но теперь она переназначена для «расширенных клавиш выбора текста». Поскольку «ExtendedEditkeyCustom», похоже, больше не реализуется за пределами рудиментарного макроса
CONSOLE_REGISTRY_EXTENDEDEDITKEY_CUSTOM
в исходном коде, я думаю, чтоIsPauseKey
должен просто возвращать true дляVK_PAUSE
или Ctrl-S, что восстановить исходное поведение.В соответствующей заметке в источнике я вижу, что «ExtendedEditKey» и диалоговое окно свойств задают значение global
g_fEditKeys
, но оно, похоже, не используется.