82 replies to this topic

[Joy2DWorld]

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.

eg:

#b::
tooltip  no way!!!
return

the 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).

note:

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.

[trik]

Maybe because that's what you tell them to do? It's not Chris's fault if he wanted to give a little flexibility in hotkeys.

[Joy2DWorld]

Maybe because that's what you tell them to do? It's not Chris's fault if he wanted to give a little flexibility in hotkeys.

ahhh yes... if they did what we told them to do then it wouldn't be a BUG, now would it...

and,

FLEXIBILITY is *FANTASTIC*, and hope we will have it...

the FLEXIBILITY not to send control key presses when a hotkey is ACTIVATED!!!!!

ie.

$#a:: 
tooltip  no way!!! 
return

what about this code suggests any desire to trigger control key presses ????

ps:@dieom,

did you clip the tiny code & run it ? (I use SciTe which allows (as do other eds) running directly from notepad vew)....
and did you see the same bug ? (ok, this one is tricky because you also need to know how to monitor for control key presses...)
anyhow... just a tip... (like looking up commands in the help file.. it has a really great search and index...)

[Joy2DWorld]

any maybe need to be more clear ??

CONTROL KEY PRESSES ARE SENT WHEN A HOTKEY IS ACTIVATED....

NOT ONLY ALT HOTKEYS,

but WIN KEY HOTKEYS AS WELL!!!!

ie. control is sent when Win Key is released....

(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!!!)

[Sean]

ie. control is sent when Win Key is released....

Win Key too to prevent Start Menu activated.

[Lexikos]

(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!!!)

What troubles are these control key presses causing you? Surely there are workarounds...

[Joy2DWorld]

What troubles are these control key presses causing you? Surely there are workarounds...

Troubles:

many systems use single or double control to shift language entry. Thought AHK would be fantastic to program install & config to distribute to students...

but alas...

the out of control control key press... killed it....


workaround...

Indeed there is true genius in this community....

perhaps one can find a way ?....

but....

wouldn't it just be SO MUCH SIMPLER!!!!!! if sweet pleas and swollen eye tears for help... might soften the heart of Chris... to include a #TURNOFFAUTOCONTROLKEYPRESSES option........

which would ... be... ahhhh..... so much simpler ??, yes ?

[trik]

My god man. There is no reason to flame. I'm sure Chris has seen and taken note of this. And yes, I did test the code and according to what you want it do caps lock must be active to do so. So I don't know what your complaining about the "win key" creating a tooltip. Like I said in my first post. "You wanted it to do so." If you don't want it to use the win key then don't tell it to..

[Lexikos]

My god man. There is no reason to flame.

I agree. Cool down, Joy2DWorld...

I don't know what your complaining about the "win key" creating a tooltip.

I think maybe you misinterpreted "controls" as meaning the tooltip. Since this isn't the first thread Joy2DWorld has started about this issue, I already knew "controls" referred to "(simulated) control keypresses". Chris has already stated that it is by design and necessary. He also mentioned a workaround.

I think turning it off would cause a lot more harm than good. Many scripts and hotkeys would be broken because the menu bar would become active (selected) after the ALT key is released.

One way to work around this is to add another modifier to your Alt hotkeys. For example, I don't think the hotkeys #!a and ^!a would send the Control keystrokes.

Just out of curiosity, I tried disabling the code that sends control keypresses to suppress menus (DisguiseWinAltIfNeeded() and at least one seperate instance of KeyEvent(KEYDOWNANDUP, VK_CONTROL)). Releasing the windows key after pressing win+a causes the start menu to pop up. Releasing alt after pressing alt+a causes the menu bar to activate. Either way there is no point in disabling the control keypresses.

I did, however find another workaround - don't use the keyboard hook. For example, instead of:

#IfWinActive foo  ; causes keyboard hook to be used
#a::tooltip foo

use

#a::
  IfWinActive, foo
  {
    tooltip foo
  }
  else  ; this bit is only really necessary if #a actually does anything...
  {
    Hotkey, #a, Off
    Send #a
    Hotkey, #a, On
  }
return

Instead of ctrl down-and-up, it seems to send ctrl+win. I imagine that shouldn't be a problem, though, considering it's really no different to ctrl+s or ctrl+o.

many systems use single or double control to shift language entry.

Is that a Windows feature? As far as I can tell, Windows only has Ctrl+Shift, Left Alt+Shift or Grave Accent (`) to switch input languages.


So to answer your question:

which would ... be... ahhhh..... so much simpler ??, yes ?

Yes, if you want the start menu to show every time you press the hotkey, otherwise, no.

[Sean]

I think I once experimented on this, why then system hotkeys defined through RegisterHotkey don't show this symptom. OK, it's the System, so it could know everything about what's going in and out. Besides that, 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.

[Sean]

I just looked at my script (written in other app) where I had to do a similar job myself to not activate File/Start menu when the modifier key is Win or Alt. I used and stll use lots of hotkeys with (Left/Right) Win key as a modifier.
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.

[Lexikos]

Actually, the key wasn't Ctrl key, seeming an artificial non-existent key like SC:05D, VK:FF.

Interesting. I replaced all instances of

KeyEvent(KEYDOWNANDUP, VK_CONTROL)

(5 in hook.cpp, 1 in keyboard_mouse.cpp) with

KeyEvent(KEYDOWNANDUP, 0xFF, 0x0FF)

and it seems to work. Instead of Control keypresses, it generates:

FF  0FF	i	d	0.00	not found      	

FF  0FF	i	u	0.00	not found

(0x05D also works in place of 0x0FF.)

[Sean]

KeyEvent(KEYDOWNANDUP, 0xFF, 0x0FF)

and it seems to work. Instead of Control keypresses, it generates:

FF  0FF	i	d	0.00	not found      	
FF  0FF	i	u	0.00	not found

(0x05D also works in place of 0x0FF.)

Interesting. BTW, the key was one key: SC05DVKFF.
Scancode used to have to not exceed 0x7F, the values above it used to be for Release, i.e., KeyUp.
I don't know if this rule is still applicable.
SC05DVK5D looks a bit risky to me as SC15DVK5D is the app key.
But they work in your experiment. Intriguing!

[Lexikos]

Note the extra '0' in '0x0FF'. I had the virtual key-code as 0xFF both times. Using 0x5D (VK_APPS) probably would've worked, but also probably would've triggered a context menu... I actually used VK 0xFF, SC 0x05D first, then changed the ScanCode to 0x0FF.

If values above 0x7F are for key-release, I guess 0xFF is the 'release' equivalent of 0x7F.

[Sean]

Note the extra '0' in '0x0FF'.

I see, I thought you meant SC05DVK5D.
BTW, the part I'm really interested in is the KeyUp-Only part: whether it would work or not without breaking the exsting scripts.
Although I no longer use the script mentioned, moved all the hotkeys in it to AHK, I had never experienced a problem with it as far as I'm aware.