The problem
Recently, a colleague inadvertently froze a running Uplink-based program, running in a Windows Console. This console instance was vulnerable because it had Quick Edit Mode enabled:
As a result, any mouse-click inside the console text (see the highlighted character cell below)
is interpreted as step 1 in the following copy-to-Windows-clipboard sequence:
- Mark the text to be copied (e.g., with menu, arrow keys, or mouse)
- Copy the text (e.g., with menu or Enter key)
Once step 1 begins, Windows attempts to hold the console text steady. To do this, it must pause any program that is writing to that console window.
If that happens to be your uplink-based program, FYI-logging a processed job to the console, then that’s a problem. The program will be paused at the point where the first character would get written to the console. Subsequent steps, e.g., returning from the Uplink-invoked function, will not occur until step 2 completes.
If nobody notices – after all, the highlighted character cell just looks like a big cursor – that could take awhile.
A solution
This solution is courtesy of Stack Overflow.
Using the provided code as a module, I wrote
def disable_quick_edit_mode(restore=False):
mask = ENABLE_QUICK_EDIT_MODE
flags = ~ ENABLE_QUICK_EDIT_MODE
update_console_mode(flags, mask, restore=restore)
You can call this function at program start. If you’re paranoid about a user manually enabling Quick-Edit Mode, you can also call it immediately before invoking any console output routine (e.g., print
).
Note that there are still other ways to pause output in a Windows Console, and in Terminal windows (e.g., CTRL-S). These should be dealt with separately.