AutoHotkey Community

Interesting indeed.


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

_________________
Joyce Jamce

Using KEYUP instead of KEYDOWNANDUP seems to work equally well, but only puts one "not found" in the key history instead of two.

and

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

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

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

Nonsense.Also nonsense. If you load another #a:: script after the workaround, it will override the workaround so #a will never even be sent.
test1.ahktest2.ahkIf 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.

interesting.

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





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:




Script #2, run it next:




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

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

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

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

#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: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...


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

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

Thanks for that info. It has already proved valuable to others here, and I expect it will help me in the future.

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.

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?

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.

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 ?