The first issue is likely due to the following change:
Hotkeys now mask the Win/Alt key on release only if it is logically down and the hotkey requires the Win/Alt key (with #/! or a custom prefix). That is, hotkeys which do not require the Win/Alt key no longer mask Win/Alt-up when the Win/Alt key is physically down. This allows hotkeys which send
{Blind}{LWin up} to activate the Start menu (which was already possible if using a remapped key such as
AppsKey::RWin).
Source: Changes from v1.1 | AutoHotkey v2
It is easier to take action in script than it is to work around unwanted actions that are taken automatically.
The first difference in behaviour between having or not having
LWin & Q:: is that the keyboard hook is designed to never suppress the prefix key in a custom combination if it is a standard modifier key, probably because:
- Unlike custom modifiers like Tab in Tab & Q::, the standard modifier keys are already designed to cancel out their native function when they are used in combination with another key, so do not need to be completely suppressed.
- Most users wouldn't expect a hotkey like LWin & Q:: to implicitly disable all of the native functions of LWin (and combinations which include it).
The second difference in behaviour is due to this rule:
Fire on release: The presence of one of the above custom combination hotkeys causes the
release of Numpad0 to perform the indicated action, but only if you did not press any other keys while Numpad0 was being held down. This behaviour can be avoided by applying the tilde prefix to either hotkey.
Source: Hotkeys - Definition & Usage | AutoHotkey v2
On a related note, a technique similar to [
using the up suffix] is to make a hotkey into a prefix key. The advantage is that although the hotkey will fire upon release, it will do so only if you did not press any other key while it was held down. For example:
Code: Select all
LControl & F1::return ; Make left-control a prefix by using it in front of "&" at least once.
LControl::MsgBox "You released LControl without having used it to modify any other key."
Attempting to mask LWin by sending a keystroke
after it is released doesn't work very well, although on Windows 10 it might cancel out the menu with some brief flicker.
So to be clear:
- LWin:: on its own fires on key-down and suppresses it, not only suppressing the Start menu but also preventing any use of LWin as a modifier in standard system hotkeys.
- Once LWin & Q:: is added to the script, LWin:: fires on key-up and does not block key-down/up. Since it isn't blocked, it can be used in standard system hotkeys, and may trigger the Start menu if no other keys are pressed or sent before it is released.
- v1 automatically masks the release of LWin when LWin:: fires, because LWin is both physically and logically down; the actual hotkey is not taken into account.
- v2 does not automatically mask the release of LWin, because LWin:: does not "require" LWin (that is, LWin is not a prerequisite modifier of the hotkey; the key is not considered to modify itself).
I will consider how this can be improved.
Personally, I would not use the
custom combination syntax to define combinations that aren't custom.
For standard modifier keys, normal hotkeys typically work as well or better than "custom" combinations. For example, <+s:: is recommended over LShift & s::.
However,
<#Q:: affects the behaviour of
LWin:: in the same way. It was probably assumed that the user would still want to use LWin to activate
<#Q::. If LWin is suppressed, the only way to activate
<#Q:: would be via remapping (
xxx::LWin).
On the other hand, the current behaviour makes it very difficult to suppress
LWin:: when
<#Q:: is also present. I'm currently wondering why I haven't changed
LWin:: to always suppress, since
~LWin:: can and should be used if suppression isn't desired, but it's late here; I'm tired and might be forgetting something.
