Page 1 of 1

Ctrl:: hotkey firing on press instead of release

Posted: 21 Apr 2019, 23:32
by bodys
[Moderator's note: Topic split from SendInput, {Raw}"{Tab}" -> Control key stuck]

On my PC (AutoHotKey U64 and win10 with Japanese 106 keybd), I couldn't reproduct the problem with Leli196's and Rohwedder's scripts.
But similar Ctrl problem occurs these two scripts below.

1st script:

Code: Select all

;force Admin (No reproducibility without Admin)
#SingleInstance force
	Run,% "*RunAs """ . A_AhkPath . """ """ . A_ScriptFullPath . """"

Menu,menu1,Add ;create menu

2nd script:

Code: Select all

ToolTip,% A_ThisHotkey
If I run the 1st script as Admin and the 2'nd script as Non-Admin and press Shift + F1(+F1::), Ctrl + A executes Ctrl:: instead of ^a::.

Also Adding #InputLevel 1 or removing #UseHook at the 1st script, the problem occurs.
Removing Ctrl:: or Shift:: at the 2nd script or running the 2nd script as Admin, no problem occurs.

Hotkey Type of 1st:
KeyHistory of 1st:
Hotkey Type of 2nd:
KeyHistory of 2nd:

Re: Ctrl:: hotkey firing on press instead of release  Topic is solved

Posted: 22 Apr 2019, 03:47
by lexikos
Your issue is unrelated to the original one, so I have split the topic.

Your issue is a consequence of security features of the OS.

Specifically, UIPI. Your admin script steals the focus while the Shift key is being held down, so the Shift key is released while the admin script has the focus. Processes of a lower integrity level than the active window cannot capture keystrokes, so the non-admin script thinks that Shift is still held down. This can be seen in KeyHistory.

When the issue occurs, Ctrl+A is not triggering the Ctrl hotkey; you are pressing Ctrl, which is triggering the hotkey, then you are pressing A, which is doing nothing because the Ctrl keypress was blocked by the hotkey.

Understanding the problem may require first understanding how the plain modifier keys are handled, which may require understanding how custom combination hotkeys work.

Normally, when you write a hotkey x::, x executes immediately when you press it (and that is what is happening to you with Ctrl when the issue occurs). This would not be ideal if you want to use combinations like x & y::, since pressing x would execute the x hotkey before you get a chance to press y. Therefore, the presence of this hotkey turns x into a prefix key.

When a prefix key is pressed down, the keyboard hook records that it is pressed, and goes through a bunch of other logic. If you press another key or hotkey, the keyboard hook assumes that you are using the two keys in combination, so it does not trigger the prefix key's hotkey (x:: in my example) when you release the key. When you release the prefix key, the keyboard hook records that there is no longer a prefix key held down.

If you use them as hotkeys, standard modifiers such as Ctrl and Shift go through the same logic so that you can still use them as modifiers for system hotkeys or the active window. That is, the presence of Ctrl:: and Shift:: turns these two keys into prefix keys.

The keyboard hook only allows for one prefix key held down at a time. Custom combination hotkeys do not support combinations of more than two keys, and since the fire-on-release behaviour of the standard modifier keys utilizes the same code, it doesn't either. While you don't think you are holding both Shift and Ctrl, the script does, because (as I explained above), it was unable to detect Shift-release.

I was able to work this out because of one essential line in KeyHistory (a line that you omitted):
Prefix key is down: yes

Your issue can be reduced to this:
  • Run the script below (not as admin).
  • Activate any window that does not belong to a program running as admin.
  • Hold down Shift.
  • Activate (without releasing Shift) any window that does belong to a program running as admin - any program, but it must be running as admin.
  • Release Shift.
  • Press Ctrl. Nothing happens, because the script can't see what's going on while this window is active.
  • Reactivate the first window, or any other window that does not belong to a program running as admin.
  • Press Ctrl. The tooltip will appear immediately when you press it, not when you release it. Combinations of Ctrl + something else will not work, because Ctrl is blocked.
  • Press and release Shift.
  • Ctrl will now function normally, because the script was able to observe Shift-release.

Code: Select all

ToolTip % A_ThisHotkey
I believe you should be able to avoid this issue by using Run with UI Access, which allows hotkeys (and the keyboard hook in general) to work even if the active window is running as admin. It does not give the script admin rights, but it does allow the script to take control of other programs (by sending keystrokes) which are running as admin.

Another option is to wait for Shift to be released before you show the menu. Note in that case, you may see a "Shift" tooltip, because the script detects Shift-release but not F1 (because it is suppressed by the other script).

Also note that the issue does not occur if you release Shift after the menu is closed (assuming a non-admin window becomes active at that time).

Re: Ctrl:: hotkey firing on press instead of release

Posted: 23 Apr 2019, 00:22
by bodys
Thank you for your explanation!
I understood that my case is not coresponding Leli196's topic.
Another option is to wait for Shift to be released before you show the menu.
Following your advice, it comes to work fine by adding this before Menu,Show at 1st script.

Code: Select all


Re: Ctrl:: hotkey firing on press instead of release

Posted: 24 Apr 2019, 18:24
by lexikos
This is what KeyWait is for.

Code: Select all

KeyWait, Shift