AutoHotkey Community

[Guest]

[Chris]

Does it happen in all applications and editors, or only one in particular? You might try increasing SetKeyDelay to see if that helps: SetKeyDelay, 50

Finally, if you have another NT4 computer to test this on, it would be helpful to discover if it has the same problem.

Edit: One possible workaround is this:
send, {CtrlUp}text{SPACE}text{ENTER}

Maybe beardboy or someone else with access to NT4 can try to reproduce this.

[beardboy]

I tested on an NT computer and I get the same results "ext text". I was using Metapad as my editor and CTRL+T in metapad with hide / show the toolbar, so as it ran through the characters of "text text" it would hide / show it with each "t". I ran the same test on my 2000 laptop without a problem.

thanks,
beardboy

[beardboy]

I just tested compiling the same script with version .07, .08, .09, and .10, all with the same results.

thanks,
beardboy

[Chris]

What would be helpful also, if someone has time, is a copy & paste of the relevant part of the key history window text, perhaps just for a hotkey like this to keep it short (assuming it has the same problem):

^a::send, t

I suspect what is happening is that AHK is sending the first character too soon after releasing the control key (it sends the first character almost instantaneously after the release, not using KeyDelay). If so, it seems that although Win2k/XP and perhaps even 9x can keep up, NT cannot.

I imagine all of these NTs that were tested have at least SP3 installed, since there are significant changes to keyboard functionality in that pack, I think.

Thanks both of you for reporting this and your help in testing it. I think it can likely be fixed by adding a Sleep(0) in the code right after the modifiers are released (but I'd do this only for NT to minimize the side-effects).

[beardboy]

The computer I am testing on has Service Pack 6a.

[Chris]

Wow that was fast! Anyway, that's good because it shows that my theory was wrong. Instead, on NT, AHK is not sending the CtrlUp event as it should, probably because there's a problem detecting the control key's state.

One more test, at your leisure, should help me:

#InstallKeybdHook
^a::
KeyHistory
return

On XP, KeyHistory's top part shows this:
Modifiers (GetKeyState() now) = LCtrl
Modifiers (Hook's Logical) = LCtrl
Modifiers (Hook's Physical) = LCtrl

It also shows RCtrl if I pressed that instead. Can you see what it says on NT for both RCtrl+A and LCtrl+A? Thanks again.

[beardboy]

On NT it does the following:
Modifiers (GetKeyState() now) =
Modifiers (Hook's Logical) = LCtrl
Modifiers (Hook's Physical) =

And with the RCtrl+A:
Modifiers (GetKeyState() now) =
Modifiers (Hook's Logical) = RCtrl
Modifiers (Hook's Physical) =

thanks,
beardboy

[beardboy]

After all my screw ups in testing , a simple fix for the guest is to just install the keyboard Hook.

[Chris]

Thanks to beardboy's tireless testing, I think this issue (which affected only NT4) is resolved in v1.0.11.

Final verification is pending; if anyone notices this any other issues still unresolved on NT4, I will try to fix them.

[Seal]

I seem to have this problem with AHK ver. 1.0.15 and Windows XP (no SP) and notepad. It seems that AHK is not releasing the ALT key fast enough so that

!a::Send, FIND A KEY...

is opening the file menu of notepad. I have tried

!a::Send, {ALTUP}FIND A KEY...

but it still does not work. Tried InstallKeyHook, Sendkeys 0, SendWinKeys 0 all to no effect, the Key histry shows that this hotkey is not using keyhook. So I used !$a::Send etc. but still the behaviour is the same. I have found a workaround,

!a::Send, zFIND A KEY...

This sends an ALT-z at the begining so that notepad tries to open a menu with hotkey z (Thank GOD nobody uses such a menu item as far as I know). This makes windows release the ALT key. But this is really a bother!
Help please! Thanks.

[Chris]

This is a known issue as described in the FAQ at http://www.autohotkey.com/docs/FAQ.htm

How to avoid trouble with ALT hotkeys that use the Send command?
The trouble is caused by the fact that the ALT key tends to activate the menu bar of the active window. The following example shows a workaround that may fix the problem in some cases: !a::Send, {AltUp}{Alt}Text To Send.

There is an item on the to-do list to try to improve this. However, I fear there might be no way to do so without potentially breaking some existing scripts that rely on the current behavior. Suggested approaches are welcome.