I appreciate all the research and findings that have been posted. While I can see that there is some reason to change the current behavior, there are also several reasons against it:[*:bfzbsp5o]Although the "control-up only" method appears to work the Alt key, it doesn't work for the Start Menu (at least not always). Thus, it wouldn't be a complete solution.
[*:bfzbsp5o]Sending the 0xFF virtual key instead of VK_CONTROL has a significant risk of breaking existing scripts, especially games and other apps that might recognize and respond to any
non-modifier keystroke (even 0xFF). In fact, some apps might recognize and respond only to scan codes (ignoring the virtual keys). In such cases, if the low-order byte of the scan code matches that of any other key on any keyboard layout/language, it would probably produce unwanted characters for some users.
[*:bfzbsp5o]Any change to this area (even minor) could break existing scripts because Alt and Win hotkeys are very common, and blocking the Start Menu and the menu bar are complex areas. Therefore there's a good chance that more people would be harmed than helped. In such cases, I usually err on the side of not making any changes.
[*:bfzbsp5o]I've seen no evidence that the current behavior (control-down + control-up) affects anyone other than Joy2DWorld and perhaps one other person in an old topic. If there's evidence that this affects more than 1 out of 1000 users, please post it. Otherwise, I think there shouldn't be any changes to the default behavior due to the risk of doing more harm than good.
I think I once experimented on this, why then system hotkeys defined through RegisterHotkey don't show this symptom. ...I believe what I observed was that it suppresses only the Key-Down event, do nothing to the Key-Up event of the hotkey.
I'm not sure if this behavior would cause a problem with AHK, e.g., with KeyUp hotkeys etc.
Certainly, it'll cause annoyance like activating Start Menu if an user doesn't follow the rule of the (KeyDown) hotkeys, i.e., releasing the modifier keys before releasing the hotkey itself.
And, I'm aware of keys which generate only KeyDown event but no KeyUp event, though they are very rare.
I just looked at my script (written in other app) ...Looks like I accompanied ONLY CTRL KEYUP, not Ctrl KeyDown+KeyUp.
Actually, the key wasn't Ctrl key, seeming an artificial non-existent key like SC:05D, VK:FF.
Thanks for that info. It has already proved valuable to others here, and I expect it will help me in the future.
(please... also allow at least the flexibility to have option to TURN OFF sending CONTROL KEY PRESSES when ALT hotkey activations release the ALT key!!!)
...to include a #TURNOFFAUTOCONTROLKEYPRESSES option........
...the KeyEvent(KEYDOWNANDUP, 0xFF, 0x0FF) looks like an easy solution,
just hope can encourage Chris to include the fix *at least as an option* in the standard AHK release....
I'd like to see evidence that the control keystrokes affect a sizeable number of users. After all, pressing down the Control key in combination with ALT is extremely common (even the operating system's own built-in hotkeys seem to prefer the Control+Alt modifier combination). This implies that the extra Control keystrokes should be harmless on the vast majority of systems.
In any case, I appreciate the idea of creating a new option to change the control keystrokes into some other keystroke (or none at all) . However, without evidence that this affects more than 1 out of 1000 people, I think the option should be a low priority relative to other improvements.