4

I am facing a subtle problem, on Autohotkey 1.1.36. Please see this Esc1.ahk :

~Esc & 1:: Esc1()
Esc1()
{
    static s_count := 0
    s_count++
    tooltip, % "Esc1 #" s_count
}

The purpose of this script is: When I press combo-key Esc & 1, a tooltip appears indicating that combo-key is triggered.

Now do the following operation:

  1. Press down Esc when Notepad (or any text editor, EmEditor in my own case) on the host machine is the active window.
  2. Mouse click inside a VMware Workstation VM window.
  3. Release Esc.
  4. Mouse click EmEditor, making it host-machine active window again.
  5. Press key 1, one or more times.

Now, surprising thing happens, tooltip Esc1 #2, Esc1 #3 etc appears, and the letter '1' does NOT get typed into the text editor -- although we have already released Esc.

We can easily imagine what has happened: When we deliberately release Esc not from the host machine but from inside the VM, Autohotkey engine running on the host machine does not get Esc's KEYUP event, so in step 5 above, Autohotkey still thinks the Esc key is being pressed down. This weird behavior persists until we press and release Esc again, from a non-VM window.

So my question is: Is it possible to detect this exceptional situation from our own AHK script, and, what AHK statements can be used to recover from this? By saying "exceptional", I mean: when the physical key-state is actually UP, while Autohotkey engine thinks it is DOWN.

When this mismatch symptom happens, GetKeyState("Esc", "P") returns 1, which means "key pressed", but the physical key state is released. No luck yet.

enter image description here

enter image description here

Jimm Chen
  • 3,411
  • 3
  • 35
  • 59
  • If even `GetKeyState("Esc", "P")` returns an incorrect value, I'd probably look into if there's something to be done on window losing focus event. If all else fails, you could of course go to the hardware level and detect keys accurately with e.g. [AHI](https://github.com/evilC/AutoHotInterception). What's your actual use case here though? Maybe I could recommend something else if I knew what your issue actually is and how it happens (in practise). – 0x464e Feb 17 '23 at 10:13
  • That may be an interesting tool, good to know it. Thank you. But, Francisco Lopes's kernel-mode filter driver(keyboard.sys and mouse.sys) does not seem to be opensource. – Jimm Chen Feb 17 '23 at 16:08
  • Yes, that is unfortunately true. I'm not aware of an alternative though. – 0x464e Feb 17 '23 at 16:10

0 Answers0