Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Extraneous control key presses generated by #or ! hotkeys!


  • Please log in to reply
82 replies to this topic
Joy2DWorld
  • Members
  • 562 posts
  • Last active: Jun 30 2014 07:48 PM
  • Joined: 04 Dec 2006

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



Interesting indeed.


(@ Sean, That's brilliant!!!)
Joyce Jamce

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Using KEYUP instead of KEYDOWNANDUP seems to work equally well, but only puts one "not found" in the key history instead of two. :)

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Jun 30 2014 07:48 PM
  • Joined: 04 Dec 2006

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.

and

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:


1. Yes on my own system it is ctrl+shift, which is why didn't encounter the AHK problem originally. There is, as have learned the hard way!!! a freeware tool allowing use of just the control key, via long keypress or via single/double press.

in looking into issue, found about half a dozen programs that use the naked control key as a program trigger or shortcut.

2. stopping the startmenu popup is (if not otherwise obvious) needed, but can be done intentionally from within the triggered script.

3. am a HUGE fan of AHK, and just have some frustration that some fundamental 'issues' didn't make it to the language doc file....

4. 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....

having to worry about distributing a forked AHK version kills part of the idea, of using the install to share/educate about the powers of AHK...

(hmmm... worse than that.... apparently can only compile if you have NET 2.0+ installed... uggg.... well.. that's MS foryou...)
Joyce Jamce

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Jun 30 2014 07:48 PM
  • Joined: 04 Dec 2006
KeyEvent(KEYUP, 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....



note that
#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

isn't really a workaround as the 'sent' hotkey will get missed by other programs depending on the hook order...


ie. if non-obvious, loading a #a triggered hotkey script before, and another after this 'work around' , you should find that the sent #a is only sent to the subsequently run script...

ie. this 'workaround' not work...

but KeyEvent(KEYUP, 0xFF, 0x0FF) looks like an easy solution,

hope can encourage Chris to include the fix *at least as an option* in the standard AHK release....
Joyce Jamce

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

(hmmm... worse than that.... apparently can only compile if you have NET 2.0+ installed... uggg.... well.. that's MS foryou...)

Nonsense.

isn't really a workaround as the 'sent' hotkey will get missed by other programs depending on the hook order...


ie. if non-obvious, loading a #a triggered hotkey script before, and another after this 'work around' , you should find that the sent #a is only sent to the subsequently run script...

Also nonsense. If you load another #a:: script after the workaround, it will override the workaround so #a will never even be sent.
test1.ahk
#a::
    Hotkey, #a, Off
    Send #a
    Hotkey, #a, On
    msgbox #a sent
return
test2.ahk
#a::
msgbox #a
return
If you load test2.ahk second, it overrides test1.ahk - i.e. #a is never sent. If you load test2.ahk first, test1.ahk sends #a and properly triggers test2.ahk.

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Jun 30 2014 07:48 PM
  • Joined: 04 Dec 2006

(hmmm... worse than that.... apparently can only compile if you have NET 2.0+ installed... uggg.... well.. that's MS foryou...)

Nonsense.


interesting.

You can compile it without the MS Net 2.0(+) framework installed ?!


Also nonsense. If you load another #a:: script after the workaround, it will override the workaround so #a will never even be sent.



what ?!??!!


in AHK you can limit the intercept of the hotkey via #IfWinActive

which allows bypass-non-intercept of the hotkey.

so if script #1 (LOADED FIRST OR SECOND) has a hotkey #A, but limited with #IFWinActive... then pre or post loaded scripts or programs still get the #A...........

you suggest work-around, not using #IfWinACtive, ie. not using this hook structure...

but the suggestion doesn't work, as explained above...... the script sent #a is only sent to the subsequently run script... and NOT a prior loaded one...


script #1 first run this:

#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.

#ifwinactive Test

#a::

msgbox you got me !!

return


Script #2, run it next:

#a::
 
 send #a
 
 
 return


and you will see clearly that the second script IS run, but the first one not (assume from window start with "Test").


which is all to say that, attempting to use a 'send' in conjuction with a window test, as an alternative to #IFWinActive .... just doesn't work unless you happen to have all the script load in exactly right order...

with that... the the KeyEvent(KEYUP, 0xFF, 0x0FF) does sure look like a great solution,

and just hope can encourage Chris to include the fix *at least as an option* in the next AHK release....
Joyce Jamce

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

(hmmm... worse than that.... apparently can only compile if you have NET 2.0+ installed... uggg.... well.. that's MS foryou...)

I think that might be the case if using VC++ 2005 Express but AFAIK the VC++ 2005 Express installer should take care of that for you unless you have beta versions installed that may cause conflicts. Here's a page that may give info if that's the case. I don't understand though... If you have gone to the trouble of installing VC++ and the necessary SDK libraries then why is having to install .NET 2.0 (+) (if necessary) an issue... ?

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Jun 30 2014 07:48 PM
  • Joined: 04 Dec 2006

If you have gone to the trouble of installing VC++ and the necessary SDK libraries then why is having to install .NET 2.0 (+) (if necessary) an issue... ?

support number of systems with limited HD space, they simply cannot afford the net2 overhead. If add net2, no longer easy to debug program conflicts, especially net1/2 related.

net2 runs way to slow in virtual machine.... (unless somehow missed a key part of install... when tried it...)
Joyce Jamce

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

If you have gone to the trouble of installing VC++ and the necessary SDK libraries then why is having to install .NET 2.0 (+) (if necessary) an issue... ?

support number of systems with limited HD space, they simply cannot afford the net2 overhead. If add net2, no longer easy to debug program conflicts, especially net1/2 related.

net2 runs way to slow in virtual machine.... (unless somehow missed a key part of install... when tried it...)

.NET 2.0 is not necessary to run AutoHotkey.exe after compiled AFAIK...

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

and you will see clearly that the second script IS run, but the first one not (assume from window start with "Test").

#IfWinActive forces the use of the keyboard hook, and as a side-effect prevents simulated input from triggering the hotkey. The hook order has nothing to do with it. Heck, one script isn't even using the keyboard hook.

The workaround must be applied to every script that uses the hotkey. For example:
#a::
  ifwinactive, ahk_class Progman
  {
    msgbox desktop!
    return
  }

  hotkey, #a, off
  Send #a
  hotkey, #a, on
return
#a::
  ifwinactive, test
  {
    msgbox you got me !!
    return
  }

  hotkey, #a, off
  Send #a
  hotkey, #a, on
return
These will work regardless of the order they're loaded in. (Neither uses the keyboard hook.)

Hey, wasn't the original purpose for the workaround to avoid those control keypresses?? If you only apply the workaround (remove the hook) to one script, the other will still generate control keypresses... :p


If I recall correctly, the Windows SDK (formerly known as the Platform SDK) includes a VC++ compiler; and it's free to download. I'm quite certain it doesn't require the .net framework. It likely won't be as simple to set up, though.

I think that might be the case if using VC++ 2005 Express

Can you even install VC++ Express without the .Net Framework? It can't build native win32 apps out-of-the-box...

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

I think that might be the case if using VC++ 2005 Express

Can you even install VC++ Express without the .Net Framework? It can't build native win32 apps out-of-the-box...

That was the point. If you quote a bit further... ;)

I think that might be the case if using VC++ 2005 Express but AFAIK the VC++ 2005 Express installer should take care of that for you...



Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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.

Thanks.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
Perhaps a beta (or unofficial) release could be put together for people to test to see if an alternative method could be used without introducing unwanted side effects?

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
If anyone wishes to do that, I'd welcome it. However, I think the criteria would be that the change should adversely impact no more than 1 out of 1000 users (unless someone comes up with evidence that the current behavior impacts more than 1 out of 1000). To determine that statistically, it seems that at least 3000 users (simulated or real) would need to test their scripts in a broad variety of applications, games, keyboard layouts, and languages.

J2DW as guest
  • Guests
  • Last active:
  • Joined: --

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.



gosh,

you obviously know best, but we're talking about merely parsing one additional #TURNOFFUNWANTEDCONTROLKEYPRESSES directive,
and making what is the up/down send based on that... (ie. control vs. 'null'/'non-key/0xFF).



*EVERYONE* who uses the 'find cursor by control key press' option of their Windows is annoyed by a floating circle at evey hooked alt or winkey hotkey activation.

*EVERYONE* who uses any of the control key based apps.. is effected.

maybe it's just an annoyance for them,

maybe they just mark it up as AHK is not compatible with them, and move on...



but ... gosh...



tiny amount of coding to add option of 'taming' an AHK behavior...

seems like that makes AHK better... yes ?