22 replies to this topic

[BrandonHotkey]

I reported it closely here:
<!-- l --><a class="postlink-local" href="http://www.autohotkey.com/community/viewtopic.php?f=1&t=87130&p=541190#p541190">viewtopic.php?f=1&t=87130&p=541190#p541190</a><!-- l -->
AHK is unpredictable and unstoppable. It continues having control over my K/B even I exited the AHK.

[Lexikos]

I understand that those sort of problems can be very frustrating, but AutoHotkey is only part of the picture. In my personal experience (as a script author and user of AutoHotkey), the two most common causes are improperly designed scripts and interference from "environmental" factors such as UAC or Remote Desktop.

If the keyboard state according to Windows does not match the physical state of the keyboard, exiting AutoHotkey isn't going to change that. Generally pressing and releasing the actual key which is stuck will unstick it, by resetting the key state to "not pressed". In some other cases, pressing Ctrl+Alt+Del allows you to regain control. I'm not sure whether it resets the keyboard state, but I have read that it cancels BlockInput and any active journal playback hooks (SendPlay).

AHK is unpredictable and unstoppable. It continues having control over my K/B even I exited the AHK.

On the contrary:

Computer programs are predictable by nature, and so is AutoHotkey given sufficient awareness of the situation. However, input processing in Windows is a complicated topic. AutoHotkey adds to the complications, as it processes various types of hotkeys and hotstrings, and has many special cases to make the various features work smoothly (for the most part) in a wide range of situations and setups. Sometimes that means there are bugs (in AutoHotkey), but it also means that AutoHotkey can't be expected to know (and do) exactly what the user intends.

AutoHotkey definitely ceases to have control over your keyboard after it exits, but that doesn't mean the problem will be magically rectified. If anything, the fact that the problem continues after AutoHotkey exits implies that AutoHotkey isn't completely to blame.

If there is a bug causing keys to stick, we need to be able to reproduce the problem before we can fix it.

[BrandonHotkey]

Happened to me again.

KeyboardAction()
{
global GE_win_search_3
SetTitleMatchMode, RegEx
  IfWinNotExist,%GE_win_search_3%
  {
  sendInput !{ENTER}
  WinActivate,%GE_win_search_3%
  }
  else
  {
  WinActivate,%GE_win_search_3%
  SendInput ^a%clipboard%+{TAB 2}{ENTER}^s{TAB}{Down 2}{ENTER}+{TAB 2}
  SendInput {F2}
  copyClipboard( 1, 200, 100, "", 1)   
  }
}
}
#ENTER:: 
  KeyboardAction()
return

This time I had to copy characters by mouse and paste them to enter the following code into script.

You could build in keyboard keys to reset when AHK script is re/started:

SendInput {ENTER up}{# up}{! up}{^ up}

[BrandonHotkey]

Code edited. The #{ENTER}:: runs the code and then the hell starts up. The Win key continues to be pressed.

As you can see, on the ind of function I send

SendInput {ENTER up}{# up}{! up}{SPACE up}

but before it, I send:

SendInput ^a%clipboard%+{TAB 2}{ENTER}^s{TAB}{Down 2}{ENTER}+{TAB 2}

but the win key is still pressed, so this is the hell that the keys have different meaning.
Yet, I will experiment with it.

Edit:
I cannot find why, but even If I reset the win key in begin of the function, It sometimes still causes problems. This happens. I send keys to open Windows to save file, then I select a folder and press F2 key to edit folder. Autohotkey crashes. I have error message asking me to send information. To Microsoft.

[BrandonHotkey]

Once more:

KeyboardAction()
{
SendInput {# up}{^ up}
global GE_win_search_3

SetTitleMatchMode, RegEx
  IfWinNotExist,%GE_win_search_3%
  {
  sendInput !{ENTER}
  WinActivate,%GE_win_search_3%
  }
  else
  {
  WinActivate,%GE_win_search_3%
  SendInput ^a%clipboard%{ENTER}
  SendInput ^s%clipboard%{TAB}{Down 2}{ENTER}
msgBox, HERE
  SendInput +{TAB 2}{F2}
  copyClipboard( 1, 200, 100, "", 1)   
  }
}

Just in the place when there is Dialog Window "Here", i want to press space to close Window, and the win key is active. So it is like Win+space and this run different code. And see that I have release the keys just in the begin of function.

I run this script on Google Earth, which is free to download. No other apps needed.

[Lexikos]

The characters !+^# are only interpreted as modifiers if they are modifying another key, such as ^a. In {# up}, # is not a modifier. {#} produces a literal # character. With the US keyboard layout, it does this by sending {LShift Down}{3}{LShift Up}. So it stands to reason that {# up} produces {LShift Down}{3 Up}{LShift Up}, not L/RWin Up.

To send or release a Win key, you must be specific: use {LWin Up} and/or {RWin Up}. For the other modifiers, it may be sufficient to use the neutral key name, such as {Ctrl up}.

I note that you send %clipboard%. What does the clipboard contain at that point? As you may be aware, the contents of the clipboard will be interpreted by the Send command as if you had written it literally in the script. Any !+^#{} characters will not be sent literally, but will have their usual special meanings.

[engunneer]

to expand on Lexikos' tip, look at Sending the clipboard as Raw using either SendRaw or Send, {Raw}%Clipboard%

Also, you may see if changing the key delay in SetKeyDelay helps.

You might also consider different SendModes, such as input. As your sent text gets longer, regular Send will take a long time. SendInput is often faster.

[BrandonHotkey]

Thanks for note. I did the corrections. Write know it contained normal characters of "sendInput". The problem did not disappear.

But here is the problem with AHK crashing
<!-- m -->http://i48.tinypic.com/jkys60.jpg<!-- m -->
when I press F2 then it crashes. Maybe it sends win+F2 causing crash...

I have

SendMode Input

Sending short strings like name of town

[BrandonHotkey]

I added on begin of script
SetKeyDelay, 20

I changed the part of sending inputs:

SendInput ^a
  SendRaw %clipboard%
  SendInput {ENTER}  
  SendInput ^s
  SendRaw %clipboard%
  SendInput {TAB}{Down 2}{ENTER}
  SendInput +{TAB 2}{F2}

Still causing crash at the exact point, when I press F2 to edit folder

note:
It does not seem that the crash has anything common with win key frozen. Before it crashes, I press pauze, that would appear a window for win+pause causes a GUI window to open. But it is still the same script in memory what is loaded. I think we could to reproduce the problem only if you would install the GE application.

[engunneer]

how about outside google earth?

SetTitleMatchMode, 2

run, notepad
Sleep, 2000
WinActivate, Notepad

clipboard = filename

  SendInput ^s
  Sleep, 2000 ;(or winwait!)
  SendRaw C:\temp\
  SendInput {ENTER}
  SendRaw %clipboard%
  SendInput {TAB}{Down 2}{ENTER}
  SendInput +{TAB 2}{F2}

also, you could try renaming using {Appskey}m instead of {F2}

[BrandonHotkey]

how about outside google earth?

I tried both, OpenOffice and Notepad and there is no problem.

I dont undertstand the AppsKey command - what is it Appskey?

[engunneer]

it opens the rightclick menu for the selected item. the m after it is rename fro english language OS. Just trying to give you an option other than F2 for renaming something.

[BrandonHotkey]

Just trying to give you an option other than F2 for renaming something.

Not. It is not my goal to rename the folder. I want to copy name to found if I am in lang directory of AHK. I use it as the simplest method to find out (relatively) where I am. Changing a way to do it does not solve the bug of crashing AHK.

[BrandonHotkey]

I am on the way to solve it. From this testing code I have removed few lines in the else branch. This does not Crash:

  #NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.

SetKeyDelay, 20 
SendInput {LWin Up}{RWin Up}{Ctrl up}{LShift Up}{RShift Up}

GE_win_search_3 = Google Earth . Nový objekt: Mnoho|Google Earth . Upravit Mnoho
save_window = 1 ; jestli to chceš hned uložit

copyClipboard( 1, max, time=100, contains="°", startpos=3){
  clipboard := ""
  sendInput ^c
  clipWait, 1
  if ( Strlen(Clipboard) < max) 
       sleep, %time%*5
  if ( Strlen(Clipboard) < max) 
       sleep, %time%*10
  if ( Strlen(Clipboard) < max) 
       copyClipboard( 1, 9, time, contains, startpos)
  if ( Strlen(Clipboard) < max AND contains<>"" AND contains<>false) 
       if ( inStr(Clipboard, contains, false, startpos) ) {
       ; msgBox, copy input 2 failed
       return 0
       }
}
  
KeyboardAction()
{
SendInput {LWin Up}{RWin Up}{Ctrl up}{LShift Up}{RShift Up}
global GE_win_search_3

SetTitleMatchMode, RegEx
  IfWinNotExist,%GE_win_search_3%
  {  ; vyvolat vlastnosti
  msgBox, %clipboard%
  sendInput !{ENTER}
  WinActivate,%GE_win_search_3%
  }
;  WinActivate,%GE_win_search_3%
  SendInput {F2}
   
}

#ENTER::
  SendInput {# up} 
  KeyboardAction()
return

I am in the Save window, but at the moment I cannot activate the WinActivate regex search because it would try to find the edit window.

[BrandonHotkey]

Crash problem resolved (partially).

The command

copyClipboard( 1, 200, 100, "", 1)

causes crash. Probably recursive call resulting in infinate loop.

In the function copyClipboard:

if ( Strlen(Clipboard) < max) 
       copyClipboard( 1, 9, time, contains, startpos)

The function loops and waits till some text appears in clipboard.

Maybe the crash is caused by the next line:

if ( Strlen(Clipboard) < max AND contains<>"" AND contains<>false) 
       if ( inStr(Clipboard, contains, false, startpos) ) {
       return 0
       }

I don't know. I can't remember how it works in details. But it should detect if the copied text is long enough and if it has search text (can be "").

I was wondering why the F2 causes crash. It is because when F2 is pressed some text (Lang) appears there and it is probably copied in the clipboard, and checked in recursive call - loop.

But it surprised me, because I thought the function is stable. I used it more times without any problem.