search

AndoDoug / uawks

Automatically exported from code.google.com/p/uawks
0 stars 0 forks source link

command+L locks the computer in vista #5

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Enable expert mode
2. Select 'use apple (command) keys as control keys
3. Press command+L

What is the expected output? What do you see instead?
- Pressing  command+L should translate to ctrl+L, and in a web browser will 
move the mouse focus to the address bar
- Instead, command+L performs the windowsKey+L action, which is to lock the 
desktop.
- In addition, after this has happened once or twice, the command key 
starts to find itself perma-depressed.  That is, typing just L will lock 
the desktop.  In addition, all of the other windowsKey combinations start 
working.  D shows the desktop, F opens search, M minimizes all windows, 
dddetc.  See http://en.wikipedia.org/wiki/Windows_key for a complete 
listing.

What version of the product are you using? On what operating system?
- UAWKS 2008.09.17
- Windows Vista Ultimate x64

Please provide any additional information below.

I attempted a workaround by disabling the ability to lock a workstation via 
a registry hack.  This indeed made cmd+L not lock the desktop, but the 
problem with the command(windows) key perma-depressed still cropped up.

Tapping a windows key (either by exiting uhawks and using command key, or 
enabling left control as a windows key) twice will fix the 'windows key 
perma-depressed' problem.

The problem seems to be with vista's handling of the windows key, and 
others using AutoHotKey seem to run into this wall.
http://www.autohotkey.com/forum/topic30115.html
http://www.autohotkey.com/forum/topic27554.html
http://www.autohotkey.com/forum/topic15513.html
I can't find a solid solution, other than using scancode remapping to 
change the windows keys to another key type (left and right control 
perhaps).  This requires a reboot, and may have unforseen consequences on 
the uhawks scripts.

Original issue reported on code.google.com by curttas...@gmail.com on 8 Oct 2008 at 3:28

GoogleCodeExporter commented 8 years ago 
Update:  I spent a good chunk of this morning trying to code a way around this 
problem, to no avail.

Eventually I settled on scancode mapping LWin to LCtrl, and RWin to RCtrl.  
After 
testing for an hour, I can't find any immediate problems with this solution.

The only real hassle with scancode mapping I've found is with Warhammer Online, 
oddly 
enough.  During the beta I had lots of issues with mapping keys to abilities, 
as the 
game seems to pull its keyboard input from an alternate source, and ignores 
scancode 
maps.  Thus, command (windows key) mapped to control would work fine in 
windows, but 
in warhammer it would treat it as the windows key again.

Original comment by curttas...@gmail.com on 8 Oct 2008 at 8:12

GoogleCodeExporter commented 8 years ago 
Expert Options as follows:
- Use command (apple) keys as control keys -- OFF
- Use left control key as a windows key -- OFF

Scancode mappings as follows:
- Left Windows (E0_5B) mapped to Left Ctrl (00_1D)
- Right Windows (E0_5C) mapped to Right Ctrl (E0_1D)

As mentioned in my previous comments, I've been using the above scancode 
mapping to 
convert the command (windows keys) to control keys, in order to avoid the 
problems 
detailed in my initial comment. I seem to have run across a related odd bit of 
behavior I thought I'd mention.

Lately I've been doing a lot of text resizing in my web browser using 
LCtrl+mousewheel.  I've found that quite often the ctrl key will become stuck, 
very 
much like the problem I encountered in my initial comment.

I'll hold down LCtrl, move the mousewheel to resize text, then let go of the 
ctrl 
key.  I'll then use the mousewheel to now scroll through the webpage, and 
instead the 
text will continue to resize.  Tapping the ctrl key a few times fixes the 
problem.  

I've also managed to run into the problem from normal uses of the control key 
(ctrl+L, ctrl+x,c,v), but its not nearly as frequent as the mousewheel 
occurances.  
The mousewheel occurances are again much less frequent than the problems I was 
having  
before I used scancode remapping, and was using the uawks expert option to map 
command to ctrl.

I found that disabling uawks caused this sticky ctrl key problem to completely 
disappear.  In light of this, I went into System Keys.ahk and commented out 
line 14 
and 15 (the two lines that control the mapping of {Left Control} --> {Windows 
Key}.

Everything seems to be working perfectly again with uawks running.  The code 
for PreferenceKeyDown and PreferenceKeyUp looks ok, but the odd behavior I've 
experienced 
seems to indicate that perhaps AutoHotKey is only sending the KeyDown portion, 
and 
forgetting the KeyUp portion.  I'll try dig into it deeper if I get a free 
moment.

Then again,

Original comment by curttas...@gmail.com on 22 Oct 2008 at 9:38

GoogleCodeExporter commented 8 years ago 
Thanks for looking into this. I've been crushed by other obligations lately, so 
your
work is appreciated. Also, unfortunately, I don't have access to a single vista 
system.

My thinking is that AHK in general is less than cooperative with other programs 
using
their own keyboard hooks (SetWindowsHookEx) and maybe some low-level keyboard
handling libraries. I've been thinking of ways around this, but it would 
probably
require an entirely different approach (registry mapping sounds attractive, as 
you
suggest, besides requirement to restart the system between changes).

Original comment by brian.jo...@gmail.com on 29 Oct 2008 at 4:41

GoogleCodeExporter commented 8 years ago 
I've run a pure registry scancode remapping solution before on both the wired 
and wireless apple keyboards.  The 
two problems there are the inability to grab the Fn or Eject keys, and the 
inability to replicate mac behavior by 
changing how the keyboard responds to things like 
shift/ctrl+up/down/left/right.  Before I discovered uawks, I 
wrote an AHK script that worked alongside my scancode remapping to replicate 
these behaviors.

I did a little digging, and it does seem possible to add scancode remapping as 
an option within AHK, without 
resorting to rebooting between changes.  Basically it would involve writing the 
changes to the registry, then 
restarting the explorer.exe process.

-- Registry scancode remapping with AHK:
http://www.autohotkey.com/docs/misc/Remap.htm#registry
http://www.autohotkey.com/forum/topic30275.html

-- How to reload the registry without rebooting:
taskkill /F /IM "explorer.exe"
start explorer.exe

I'm a little busy myself lately, but I'll try playing around with it if I get 
some time.

Original comment by curttas...@gmail.com on 29 Oct 2008 at 6:19

GoogleCodeExporter commented 8 years ago 
Here's how I *almost* solved this for myself in Windows 7:

http://www.howtogeek.com/howto/windows-vista/disableenable-lock-workstation-
functionality-windows-l/

However, it still has problems. It temporarily messes up the keyboard hooks. In 
other 
words, if you press Cmd-L, it won't log you out, but if you then press Cmd 
again, it 
will pop-up the Start menu until the next time you press ctrl...

Not a fix, but at least you won't get logged out. I'll look into this after 
some more 
pressing problems.

Original comment by brian.jo...@gmail.com on 24 May 2010 at 4:54

GoogleCodeExporter commented 8 years ago 
I've been investigating this problem full-time for about a day now, since it's 
the 
one that affects me most personally (sorry to all of my non-US keyboard friends 
who 
have more difficult problems!) Making progress, but no solution yet.

I've been digging into the AHK source code, and I've even created my own 
low-level 
keyboard hook class/app in C#, which shows the same problem but is easier to 
tinker 
with. The registry scancode remapping is interesting, but I'd prefer a less-
destructive option if possible (what if someone who isn't very tech savvy gets 
a new 
keyboard, etc?). If that's ultimately the only answer, I'll take it.

Right now, I'm both waiting to find the perfect workaround and contemplating 
ways to 
force the WinKey Up in the Win+L special case. However, it seems like Windows 
Vista/7 
purposely make this difficult.

I have a Stack Overflow post about it here: 
http://stackoverflow.com/questions/2906179/low-level-keyboard-hooks-sendinput-wi
th-
winkeyl-possible-workstation-lockout-i

Original comment by brian.jo...@gmail.com on 25 May 2010 at 4:21

GoogleCodeExporter commented 8 years ago 
I figured out a way to do this in C#, but not yet in AutoHotkey. <a 
href="http://stackoverflow.com/questions/2906179/low-level-keyboard-hooks-sendin
put-
with-winkeyl-possible-workstation-lockout-i">See my Stack Overflow post for 
more 
info</a>

Original comment by brian.jo...@gmail.com on 25 May 2010 at 7:03

GoogleCodeExporter commented 8 years ago 
Looks like the issue tracker doesn't like long links or simplified HTML, but 
I'm sure 
you can figure it out from the two posts above ;P

Original comment by brian.jo...@gmail.com on 25 May 2010 at 7:05

GoogleCodeExporter commented 8 years ago 
I still have this issue with Ctrl+L (its locking my computer instead of moving 
the nouse focus in the address bar). I am using Windows 7 Pro.
Anything new on this issue?
thx a lot

Original comment by thibaut....@gmail.com on 7 Dec 2011 at 9:05