For ALT hotkeys that use the keyboard hook like #B,#C,#D, etc., and $!a and #IfWinActive hotkeys, etc., when the hotkey is released, control keystrokes are sent by AHK to avoid activating the active window's menu bar.
#b:: tooltip no way!!! returnthe simulated control keypresses in different contexts have generated 4 threads, and
it looks like there is a simple fix (thanks Sean and lexikos) for the ahk code to avoid all the control key problems:
replace all instances of KeyEvent(KEYDOWNANDUP, VK_CONTROL) (5 in hook.cpp, 1 in keyboard_mouse.cpp) with KeyEvent(KEYUP, 0xFF, 0x0FF)
if this issue troubles anyone else, ie. if you would like to have the option to avoid AHK sending the control key presses when the hotkeys are released, seems like Chris has asked you to speak up,
short summary of some of what others have posted on the conflict:
if the script doesn't have the keyboard hook installed, it seems every time the hotkey is triggered, a control keypress is sent. Not when Alt is released; when the hotkey (!WheelUp, !WheelDown, !LButton, etc.) is triggered.
an example of a conflict. The following script causes the weapon to fire every time in Quake II (which is set to the default key - ctrl key) when pressing Alt + a . I would classify that as unwanted behaviour.
the windows show cursor tool to flash when pressing the keys
I also use Synergy to share my mouse and keyboard between two PCs at work (wonderful program), and I occasionally have the ctrl key stick on when switching between computers. I have not completely figured out what is going on, but I do have AHK scripts that send things running on both PCs. It may or may not be related to this topic, but I think it is possible.
Any hooked hotkey or #IfWinActive hotkey that has "shift" as part of the hotkey (ie. "+"), switches the user's input langauge if the shift key is the last key released. [when shift+control is set as windows' language change hotkey].
I now can get Ctrl+K instead of "k" generated (if I hold Alt+K down to cursor down in Firefox, for example).
1) keyhooks are EVERYWHERE: when you ask for them "$", when you use #IFWinACtive, and when it's 'necessary' #B, #C,#D, etc. etc.
2) when keyhooks apply, any alt (!), or winkey (#) hotkey will cause a giant animated circle to popup (at every hotkey press/release) in *every* windows system that has the 'show mouse caret' function enabled.
If this is your script on someones machine with this windows setting, it makes a mess on their every time they use a relevant hotkey....
3) other 'end' users may have single control activated programs, which will go crazy if your script is run on their machine. (this is what happened to my script and gave birth to this thread).
4) Often but not always, the AHK generated double control conflict results in the activation of google desktop search, and other DOUBLE control activated programs.
4b) Mouse hotkeys and sometimes even SINGLE HOTKEY PRESSES generate AHK generated double control key presses. The single hotkey double control conflict happens sometimes in semi-randommess way, based on length of keypress, order of keys removed, etc. (details in thread).
5) the fix is suggested/requested as an option, not breaking any existing script in any way.
there is another, quasi related conflict with shift+control hotkeys and the shift+control language selection feature of windows. The same principle might be helpful to eliminate that conflict as well, ie., to inject an u/d 0xFF keypress after the control-shift AHK generated down.