AutoHotkey Community

I often am bitten by a 'stuck' win key. Just before posting this, I downloaded and installed Version 1.0.38.05 -- September 23, 2005 to make sure I got the latest version. Here's what happens:
- I press (e.g.) Win-s to launch Rajat's 320mph.
- I click the scan button to rescan, but the windows icon task box pops up.
- Every time I click scan, the selection rectangle moves to the previous icon.
- I have to press the win key again to get rid of this box and to normalize this situation
- In some cases this brings a different window up front

I vainly searched the forum to find any mention of this type of problem. Maybe I didn't look well, or maybe I am the only guy suffering from this. Any help or pointers would be highly appreciated.

(Oh, and by the way, need I mention that I can't imagine not having autohotkey functionality, thanks Chris!)

If Win-S is a hook hotkey in your script (as show by the main window's View > Hotkeys), I think that might explain it. When a hook hotkey launches a program, the script might be tied up for a second or two, during which it is not notified of keystrokes (in this case, your release of the Windows key).

To work around this, try adding the following as the first line of your Win+S hotkey:
KeyWait, LWin ; Or use RWin if that's the one you press.

There is a plan to add a dedicated thread for the hooks that might solve this issue. But if your script and/or Win+S hotkey does not use the keyboard hook, please let me know because that might indicate some other problem. You can find out if your script uses the keyboard hook with the main window's View > Key History (near the top of that screen).

Chris,

The script does include #InstallKeybdHook.

I've put the Keywait, LWin; as first statement in the 'RunRestoreHideApp' routine which I use to toggle all my hotkey driven apps. And it seems to do the trick.

I will report any problems I would still encounter.

Thanks again for the prompt and adequate reply, you're amazing!

Guido.

I have also encountered a similar problem with sticky windows keys.

My script provides an alternative to the right click context menu when working with a group of files.

Rather than selecting files and right clicking for a context menu instead you start dragging the files and then hit the windows key. This brings up a grid of options, drop the files on the action you want executed. For instance drag the files onto the "rename" section and release, you then get another window where you can enter a regular expression. This expression is applied to all the files listed and they are renamed. ie s/\.txt$/\.TXT/ or whatever you want.

I'm currently having two problems, both of them are with things "sticking". Sometimes after dropping the files the windows key stays stuck down and craziness ensues. I'm hoping that the help from this thread will fix the problem.

The other problem I have is a delay in minimize windows and perhaps other gui operations caused by the following code:

~LButton & LWin::
Keywait, LWin ; added this from discussions in this thread
Gui, Show
WinActivate, LaunchSquare
return

With this code, clicking close or minimise in the applications title bar causes a strange delay of about half a second before the app closes or minimizes. It doesn't seem to be related to the speed of the click.

Removing this code and the problem goes away.

The delay occurs in all windows, not just those owned by the script? If so, I can't reproduce it. It might be a PC-specific issue, or perhaps something for which a more complete test-script is needed.

Actually the delay only occurs in those windows owned by the script.

Is there something I can do to get rid of the delay?

I can't reproduce that either. Try this script:
If the above does not produce an unwanted delay, perhaps you can revise it to get it to misbehave.

Your script produces the delay as does this even simpler script



Strangely, changing LWin to LCtrl or LShift fixes the behaviour. (However, RWin also produces the delay)
I have removed all other scripts and anything I can think of that might interfere, except for perhaps xmouse (autofocusing windows on mouseover - a windows registry setting)

Running XP Home SP2 with AHK v1.0.38.05

To be honest, it isn't that big an issue for the application in which it occurs but it is a little odd.

BTW.Thanks for your help, Chris, and for such a great tool.

Thanks for the follow-up.If it weren't for that, I'd suspect ~LButton of causing some timing issue between the keyboard hook and the script's own GUI window. But now I'm stumped. I can't think of any explanation other than some setting or driver that is different on your PC than mine.

If anyone else gets this behavior, please let me know.

...I get that behavior, XP SP1, AHK 1.0.38.03.

LWin = Delay
LCtrl = No delay

Now for something interesting...run the above script, hold LWin or LCtrl & click the X...the window don't close & the comp basically freezes for a while, if you click a few times while it's in this state the PC speaker will start beeping with each click or mouse move. Now change the script to use LCtrl (& not LWin) & reload...a few things change...

• The window don't delay
• Holding Ctrl & closing the window don't cause the freeze (LWin still does)
• The mouse hook isn't installed (according to the Key history & script info page) (with LWin both hooks are on).

Testing the rest of the keys...with LWin in the script...all modifier keys & alot of other keys cause the freeze (when holding down & closing the window)...with LCtrl in the script all keys BUT LCtrl & a few select others (` , . / m) (didn't test all) cause the freeze...just testing again holding m or , caused the freeze, then trying a second later it didn't...

_________________
AutoHotkey-Hotstring.ahk - Helping the world spell "AutoHotkey" correctly! (btw, it's a lowercase k!)

Thanks for the additional info. I'll try to track it down.

Weird Alright. I got the speaker thing and my mouse started moving erratically around the application window. It took about 10 seconds of clicking and pressing the LWin key before things returned to normal.

I'm using a logitech keyboard and mouse and nvidia display drivers if this is relevant. At one stage I had 2 logitech mouses connected and very infrequently(once every couple of days) a single mouse click would instantly reboot the computer. I'll check whether two sets of drivers have been installed for the difference mice ... nope.

Also, Holding CTRL or ALT or SHIFT and clicking minimize the delay shifts to about 3 seconds before minimize... actually most if not all keys cause this.

Holding LWIN and clicking minimize causes the same delay but the script doesn't minimize and after 3 seconds the start menu pops up (default behaviour of the LWIN key)

Run the following code.

Open the main window and minimize (close, maximize, or restore) it with the titlebar button. The cursor is frozen for a few seconds. Also notice, while the cursor is frozen, pressing Alt+Tab to switch windows will unfreeze the cursor and the operation (minimize, etc.) will complete immediately.

Now open the main window and minimize via the button's context menu in the taskbar. The same effect is not evident.



The freezing effect is not evident with the following code (utilizing any of the operations and methods mentioned above).



It is likely that the freezing effect is related to only the Mouse Hook. The same test can be conducted with the code in other posts by removing references to mouse "keys".

I am using:

Windows XP SP2
AHk v1.0.38.06

Edit

The effect is evident on left button down (not right button). The operation (minimize, etc.) does not have to be executed.

Today's release of v1.0.39 may have fixed the problem of a sticking Windows key and also the delay when closing/minimizing/maximizing Gui windows when LButton is a hotkey.

It's also quite possible they weren't fixed, but I can't test it because I haven't been able to reproduce either one yet.

Therefore, if you've observed any of the misbehaviors in this topic, please try again with the latest version and let me know if it's fixed or not fixed.

It turns out that the difference was caused by an entirely separate bug that failed to auto-install the mouse hook. That bug has been fixed in v1.0.39.

Initial testing indicates that this has fixed the delay and strange behaviour.

(I'll give it a more elaborate test when I get the chance)

Thanks Chris.