Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I work as a programmer, and write pretty fast (not super fast though). In my work Dell laptop I often run across two bugs, which I suspect has to do with some underlying Windows keyboard driver ("underlying", since the bugs occur on a totally different brand of keyboard as well). It is not a physical property of the keyboard, I've tried replacing the keyboard itself. Both USB keyboard, btw.

These are the strange problems:

  • The Ctrl key hangs when I type fast - but it does not hang not physically - the "release key code" never reaches the operating system, it seems like. This happens frequently, say every 20 to 120 seconds when I'm in the zone. The way to resolve it is 1) to realize that the control key is considered pressed by the system and 2) press and release the right Ctrl key. The left Ctrl key doesn't fix the bug (I know they send different scan codes).

  • The Shift key "hangs" in the same way, but there is no way to get it unlocked by pressing and releasing the shift key, there seems to be an internal counter which hangs. This happens perhaps every 10 to 20 days. To resolve I 1) have to realize the Shift key is in a pressed state (it is impossible to work with the Shift key pressed, simply selecting another file in Explorer.exe becomes impossible, not to mention trying to write code in Eclipse) and to fix it I 2) run a script I wrote for AutoHotkey, which sends {SHIFT UP} to the system. Before I wrote the script, I had to reboot the computer...

I'm getting annoyed at this. What causes this and how can I solve those problems?

Edit: here's my AHK file:

RShift::LShift

^!+r::
  ; Show a black "splash" to reveal script reloading.
  Run %windir%\system32\cmd.exe /c
  Reload
return

^!+e::
  Edit
return

; Send shift-up.
#^!+s::
  ; Send shift-up to "fix" my office laptop bug.
  SendInput {Shift Up}
return

; -------------------------

!+a::
  Run C:\Program Files\Notepad++\notepad++.exe
return

^!+a::
  Run %windir%\system32\notepad.exe
return

^!+d::
  Run %programfiles%\git\bin\bash.exe, c:\RnD\PD\trunk
return

RunExplorer(root, startTitle, subpath, endTitle, filename)
{
  SetTitleMatchMode, 3
  IfWinExist, %endTitle%
  {
    WinActivate,%endTitle%
    return
  }
  else
  {
    var = /e,
    if (root != "")
    {
      var = /e,/root,%root%
    }
    Run "%windir%\explorer.exe" %var%
    WinWait,%startTitle%,,4
  }
  if (ErrorLevel == 0)
  {
    #WinActivateForce
    WinActivate,%startTitle%
    WinWaitActive,%startTitle%,,10
    if (subpath != "")
    {
      SendInput {LAlt Down}d{LAlt Up}{End}%subpath%{ENTER}{Tab}{Tab}
    }
    SendInput {Tab}%filename%
  }
}

;Opens project home folder.
#e::
  RunExplorer("C:\RnD", "RnD", "\protustom\trunk\implementation\Protom", "Protom", "ProtomDC")
return

;Opens My docs folder.
#m::
  RunExplorer("H:\", "V0c1573 on 'Vcn.ds.volvo.net\It-got\Home07' (H:)", "My Documents", "My Documents", "Auto")
return

;Opens program files
#h::
  RunExplorer("C:\", "Local Disk (C:)", "Program Files", "Program Files", "7")
return

#k::
  Run %windir%\system32\Control.exe
return

#c::
  Run calc.exe
return

#r::
  Run regedit.exe
return

; Stores a screen shot as tmp.png on the desktop.
; Take screenshot manually before running this.
#q::
  Run c:\WINDOWS\system32\mspaint.exe
  WinWaitActive, namnlös - Paint,,15
  if (ErrorLevel == 0)
  {
    Send ^v ; Paste screenshot.
    Send !am ; Save as.
    Send +{Tab}+{Tab}{Down}{ENTER}{Tab}{Tab} ; Save to desktop folder.
    Send tmp{Tab}{Down}{End}{ENTER}{ENTER} ; Write tmp.png.
    WinWaitActive, Spara som,,2
    if (ErrorLevel == 0)
    {
      Sleep, 100 ; Wait a bit for dialog to load.
      Send {Left}{Enter} ; Overwrite previous file.
    }
    Send !{F4} ; Close paint.
  }
return


; Shift+CapsLock turns on/off CapsLock.
;Capslock::Ctrl
;+Capslock::Capslock
share|improve this question
3  
Since you mention AutoHotkey: Do you have any other scripts running? –  sudo May 24 '12 at 19:54
    
I'm not sure what you mean, but I'm running AutoHotkey with support for several keys and other functions. The same script I run on my home computer (and have run of several others), but without problems then. Are you thinking the combination of AutoHotkey and something in my laptop is causing this? I'll try shutting down AutoHotkey tomorrow to let you know if that was the perpetrator. –  Jonas Byström May 24 '12 at 21:02
3  
Are you thinking the combination of AutoHotkey and something in my laptop is causing this? It might. A script sending {RCtrl Down} without the corresponding {RCtrl Up} could explain part of what's happening. –  sudo May 24 '12 at 22:23
    
I have never heard of person that can type faster than what windows drivers can handle(unless you have incredibly slow PC). :) Joke apart, some autohotkey script seems to be the reason. Just exit autohotkey and try if the problem is still there.. This has happened with me. In some scripts with complex logic, there are some scenarios when a key does not get released. Do you mind posting your entire AHK file here so that i'll be able to look for something. –  tumchaaditya May 25 '12 at 4:43
    
I notice this behavior sometimes on my Dell Desktop. When it happens, I frantically hit the control, shift, alt keys rapidly and this usually clears it. –  Stuart Woodward May 31 '12 at 1:22

1 Answer 1

  • Ctrl key:

    I assume that the line

    Capslock::Ctrl
    

    was not commented out when you had issues with the Ctrl key.

    Different keyboards and their drivers behave differently. Some won't register when CapsLock is released, since it usually does nothing.

    On my two keyboards, pressing and releasing CapsLock sends {LCtrlDown} on one and {RCtrlDown} on the other, but never {CtrlUp}. Pressing and releasing the respective Ctrl (but not the opposite one) fixes this.

    Besides commenting the line out, I can't think of solution for this.

  • Shift key:

    I managed to reproduce the behavior you explained once, but I don't know how I did it.

    However, I assume that the line

    RShift::LShift
    

    is the culprit.

    I can't explain how a {RShiftDown} might get send with the right Shift key remapped, but it certainly explains why pressing neither Shift key fixes this, since releasing the right Shift key will send {LShiftUp}.

    There might be a solution for this other than commenting the line out, but I'm not quite sure what you want to achieve with it.

share|improve this answer
    
I don't think this has anything to do with AutoHotkey as I'm able to reproduce the bug now and then without running AutoHotkey. My SendInput {Shift Up} script resolves the annoying issue. –  Jonas Byström Sep 10 at 0:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.