AutoHotkey Community

I'm running Windows Vista Business x64 (release version 2006-11-16) and AutoHotKey 1.0.46.05. I use the Windows key as a shift to activate many actions. All worked well with Windows XP. With Vista, if the action contains a Send and the Windows key remains depressed when the characters are sent, they are interpreted as Windows shortcuts, if possible, rather than being delivered directly to the input stream. For example, if I send the string "Hello" with, say Windows-h and continue to hold the windows key down then "He" will be received by the application but the letter 'l' will lock the system, Windows-l. There is an exception when I have defined an action such as Windows-r that overrides the standard Windows shortcut. Then the letter is to the application.

I can avoid the problem if I quickly release the Windows key, before send can forward the troublesome letter. I'm thinking of adding a short wait before any Send at the beginning of an operation as a work-around.

This issue may be related to the bug report "Windows VISTA: BlockInput and other automation" posted by jptaba on Mar 23, 2006.

Thanks for the report. It's disappointing that Vista behaves differently than XP in this way; perhaps it blocks programmatic access to the Windows key.

Have you tried all the sending modes? (e.g. SendEvent, SendInput, SendPlay)
Have you tried things like "SetKeyDelay -1, 0"?

You could also try:
#x::Send{LWin up}text

If all that fails, you might try granting admin rights to the program (AutoHotkey.exe or the script itself if that is allowed).

Please let me know the results of the above because it would give more insight.

Thanks.

Chris,

I tried all of the things you suggested. SendInput, SendEvent, and sending {LWin up} didn't produce any change in behavior. SendPlay resulted in no keystrokes to the program. KeyWait, LWin did the trick but it has the awkward effect of delaying the typing of the string. That's what I'm using for now.

Running AHK as Administrator didn't change anything. I observed, as expected, that AHK will not deliver strings to programs running in Administrator mode unless AHK is also running in Admin mode.
Also, AutoHotKey.ini has to be edited as Admin or it can't be saved. All program directories seem to be locked this way, which makes sense.

Vista is certainly making life more difficult for lots of developers. Seems much more so than any of the previous versions of Windows.

From what you said, it appears that Vista blocks programmatic changes to the state of the Windows key. This is unfortunate because it reduces the convenience and effectiveness of macro utilities like AutoHotkey.

In the future, changes will be made to better support Vista. Hopefully, a better workaround can be found for the Windows key (in the meantime, I'm glad you mentioned the KeyWait method).

Thanks for posting your findings.

am i being dense or is trying with a $ prefix or forced keyboard hook worth a shot ?

_________________
Joyce Jamce

Although I don't see how it would directly help, it might indirectly make a difference somehow.

Also, maybe someone with Vista can also try out LWin::return to see if it completely blocks the LWin key (i.e. so that the Start Menu doesn't appear, and no shortcuts like Win-R work). If it does, that would be good because even though the state of LWin/RWin can't be changed programmatically, physical changes to their state can be blocked. This would help a future version of AutoHotkey provide better Win hotkeys on Vista.

Thanks.

Hmm, LWin::return does nothing but Win-R does still work. However, I've also verify that mappings such as #r::MsgBox, R override Run and show R, so Vista Windows key mappings seem OK for me.

Those results are a bit unexpected, but I'm glad to have them. Thanks for sharing them.

That was on Vista 32-bit; I noticed the OP was running x64. I do know that x64 is a lot more locked down (for example, all drivers must be WHQL signed or they will not install). Perhaps AHK just has these issues on x64? I could try to verify this.

It's not urgent because I'm sure we'll get more reports as Vista becomes more common. I'll probably get it myself one of these days -- but perhaps only for testing purposes until I find some good reasons to make it my primary OS.

Hey guys I'm an absolute rookie... and having, I think, similar issues... but not Vista.

My trouble started when I upgraded to IE 7

Changed several hotkeys from Win+X to Alt-Ctrl+X

That seems to help.

Also the alt key in IE 7 seems sticky.

I think this is the same topic, maybe not... but things got a little weird with IE7 and I'm still on XP.

I have no plans to upgrade to Vista before the third apology er I mean maintenance release.

I'm having the same problem and have a few additional data points to contribute.

1. So far, the only key combination I'm seeing this with is Win-L.

I'm using the following script:



When this script is running, LWin+D, LWin+R, LWin+E correctly act as Ctrl+D, Ctrl+R, Ctrl+E. Likewise, LCtrl+D, R, and E

perform their respective Win-key combinations.

LCtrl-L however doesn't do anything (passes l through), and LWin-L unfortunately acts like LWin and locks the screen!

2. I tried adding #l::MsgBox, L and now LCtrl-L displays the message box. This doesn't prevent LWin-L from locking the screen.

I wonder if Win-L is handled by a lower part of the OS as a security measure.

3. The $ or * prefixes don't help.

4. I'm running 32-bit Vista.

5. Intermittently, after reloading the script file, the system will act like the Win key is stuck on. Meaning, if I press D or R alone it will respond like I pressed Win-D or Win-R. This continues until I kill AHK and use a physical Win-key combination.

I hope this is helpful. I'd really love to have this working for Vista.

Yes, that's probably it. And because of it, there probably won't be a complete solution. Microsoft has apparently decided that the Windows key is the exclusive domain of the OS, similar to Ctrl-Alt-Del and the behavior of FN keys on some laptops.

Hopefully this will get fixed when I find time to install Vista. Thanks for the report.

I found a workaround (don't know if this has been posted elsewhere...)

At least for the problem I was having in Vista x64, which was that I couldn't run this script because it would press the Win+L combination and lock the computer:



Right on the "l", the problem showed up.... This is my workaraound (as there only seems to be a problem with the letter L, but could work with any letter given its proper ascii code):



Hope this help somebody

(Oh and btw, I have UAC enabled and I am running the AutoHotkey.exe with the "Run As Administrator" option turned on because of a special need while launching UltraExplorer through a AHK script ... don't know if my workaraound woulnd't work if the latter conditions didn't exist, but I think it still would).

So the problem would occur on the "myemail" part too, right? So I assume your real email address doesn't have an l in it.

Chris, can AHK do this internally?

_________________

(Common Answers) - New Tutorials Forum - Humongous FAQ