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
^a::
Ctrl::
Shift::
ToolTip % A_ThisHotkey
Return
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).
