Random "bugs" in Autohotkey? Topic is solved

[Nixcalo]

Hi fellas! This is my first post. I have been itching to write it because it's been some time I have been puzzled by Autohotkey's behaviour.

My system is moderately powerful, it is a Windows 10 24 Gb I7-6700 laptop, and some scripts do appear to have some random variable. I wonder whether it is that Windows 10 sometimes conflicts with AutoHotkey?
Take this script, for instance.

Code: Select all

^u::  
clipboard=
    Send ^x 
ClipWait
 StringUpper, Clipboard, Clipboard          ; Convert text to upper

SetKeyDelay, 90
 Send %Clipboard%
RETURN

It's the simplest script, right? Simply, it Cuts what has been selected somewhere (by sending a Control X), and then turns it to uppercase. Well, as simple as this is, I have two issues with this. First, sometimes the Control X does not work, it kind of gets "stuck" and the way to "unlock" is by physically pressing Control-C. It's as if it were waiting somewhere in the background and when I press Control C, it gets inmediately released. It happens in every script I have that sends a Control-C or Control-X (as you can imagine, those are VERY commonplace) and the behaviour is RANDOM. That is, sometimes they work perfectly, sometimes they get stuck. I would say they work 90% of the time, while the other 10%.. I have to release Autohotkey by pressing CTRL-C physically, as I said.

Now, perhaps that is a Windows issue. I have seen in some forums that Copy paste presents some problems in some users, but I don't really know whether that is the case.. it seems strange that something so basic for Windows should be giving problems at OS level, right?

Whatever the reason that may be, there is a second issue with the above script. It works... most of the time. I have checked time and time again and the conversion to uppercase is "mostly" working. By "mostly", I mean that I select the string "I want all of this to be in uppercase", sometimes I will get "I WANT ALL OF THIS TO BE IN UPPERCASE", but sometimes "I WANT ALL OF thIS TO BE IN UPPERCASE", or "I WANt all oF THIS TO BE IN UPPERCASE". In a particular case, I wanted to change "Diagnóstico" to "DIAGNÓSTICO" by using the script and the result I obtained was DIAGÓSTICO.(notice eating up an "n") That behaviour, on the contrary, is quite consistent, but not always. Sometimes, the result is DIagnÓSTico, DIAgnÓSTICO, DIagnÓSTICO (3 consecutive attemps done RIGHT now as a test)

I discovered that adding the SetKeyDelay, 90 improved things in a percentage (that is, they tended to work better, not perfectly but better)

Any ideas? I will give a last piece of information. These problems tend to happen within Trados Studio. I have been performing this procedure in MS Word or Notepad for 10 times in a row and they seem to work 100% of the time. So the question might be "Does anyone have this similar problem with Trados Studio"? Might it be that this particular software conflicts with Autohotkey in a way (by an internal process or something) that gets in the way? Is there any solution, like FORCING autohotkey to take control until the script is resolved?

The issue with clipboard getting stuck seems to happen everywhere in Windows, though, very randomly. Perhaps a background thing taking use of the Clipboard? I am sure someone has to have a similar situation! Sometimes the keyboard gets stuck (it seems to be Control, or Alt, or such Function key )and the solution is to wait and press several keys randomly until it gets unstuck or, a quicker solution, kill Autohotkey. That solves the "control key stuck and interfering with Notepad, Windows, Internet Explorer and anything else"

I would appreciate some insight, as I am lost in here! I just upgraded Autohotkey to version 1.1.27.07 from 1.1.24.04 and nothign changes. If there is some other info or test I can do to narrow things down or help you locate the problem, don't hesitate to tell me so!

P.S. Meanwhile, I am going to start killing background processes and see if/when this stops happening...

[MaxAstro]

I have these kinds of problems all the time. It does seem to be an issue with AHK, unfortunately. Usually it's what I call a "timing issue" - that is, AHK is moving faster than your computer can keep up with, and the solution is to add some extra sleep to your script. The random loss of capitals is typically this sort of problem.

The copy/paste thing is actually an occasional issue with modifier keys, not with copy/paste specifically. Sometimes when you have AHK press shift, ctrl, or alt, the key will become "stuck" as AHK seemingly forgets to send a key-up or the system misses the key-up that AHK sends. When you manually press ctrl+something, physically releasing ctrl sends the key-up that got missed and fixes the problem. You can also fix it just by tapping ctrl.

So far I haven't found a 100% solution to any of these issues.

[jeeswg]

- Hopefully this script solves both problems. It uses {LCtrl Up} to avoid the modifier key issue, and it uses {Text} to solve the send keys issue (note: {Text} requires AHK v1.1.27+).

Code: Select all

^u::
Clipboard := ""
Send {LCtrl Up}^x
ClipWait
StringUpper, Clipboard, Clipboard ; Convert text to upper
SendInput {Text}%Clipboard%
return

[Cerberus]

I, too, have lots of issues with copy (control-c) being unreliable, and keys getting stuck. It also happens sometimes and unpredictably, except that it tends to occur when I'm in a rather intensive programme, such as Firefox. It also happens much more often when the keys are sent from Autohotkey than from e.g. my mouse-gesture programme. By hand, it always works. I was hoping with a new computer and a new operating system, I might be rid of this issue, but, alas, it seems that isn't the case.

As Jeeswg suggests, I often use things like this:

Code: Select all

Send {control up}
Sleep 100
Send c
Sleep 100
Send {control up}

This does help, but it doesn't solve the issue completely.

In addition, I sometimes add Send {control up}{alt up}{shift up} at the beginning of a hotkey. That also helps to some extent against stuck keys or having the wrong key in effect during a hotkey routine.

Jeeswg: is {LControl up}more reliable than {Control up}? If so, I should switch to that.

[jeeswg]

- Re. LControl/Control, I don't honestly know, but it's a good question. If that changes the state of one key and not two, perhaps it's fractionally less costly.
- You could try using ControlGetFocus and ControlSend, this may or may not have any advantage.
- This worked in Firefox, in case it's useful. WM_COPY is not guaranteed to work everywhere.

Code: Select all

q:: ;mozilla firefox - copy selected text
WinGet, hWnd, ID, A
Clipboard := ""
ControlGetFocus, vCtlClassNN, A
SendMessage, 0x301,,, % vCtlClassNN, % "ahk_id " hWnd ;WM_COPY := 0x301
ClipWait
MsgBox, % Clipboard
return

[Masonjar13]

Here's your fix: {blind}. As it seems to be known already, Ctrl is already being held, and modifier keys in hotkeys aren't hidden as the key they're modifying is. You can read more about blind mode on the send page.

Code: Select all

^u::  
clipboard=
    Send {blind}^x ; Added blind
ClipWait
 StringUpper, Clipboard, Clipboard          ; Convert text to upper

SetKeyDelay, 90
 Send %Clipboard%
RETURN

However, the clipboard appends `r to content, so if you have a line break it'll add an extra line in at least some places.

Code: Select all

^u::  
clipboard=
    Send {blind}^x 
ClipWait
 StringUpper, Clipboard, Clipboard          ; Convert text to upper

SetKeyDelay, 90
 Send % strReplace(Clipboard,"`r") ; Added removal of return carriage
RETURN

[Cerberus]

...
- You could try using ControlGetFocus and ControlSend, this may or may not have any advantage.
- This worked in Firefox, in case it's useful. WM_COPY is not guaranteed to work everywhere.
...

Hey, that's great! I'll try it for a while in Firefox, see whether it is more reliable.

[Cerberus]

Here's your fix: {blind}. As it seems to be known already, Ctrl is already being held, and modifier keys in hotkeys aren't hidden as the key they're modifying is. You can read more about blind mode on the send page.
...

So{Blind} should make the hotkey more reliable, even when both the trigger hotkey and the hotkey to send have the same modifiers, in this case control?

[Masonjar13]

So{Blind} should make the hotkey more reliable, even when both the trigger hotkey and the hotkey to send have the same modifiers, in this case control?

When you hit the hotkey, ctrl will be down. When you send ^x, control is sent down and up, making ctrl logically up, but physically down. Blind makes it so that if ctrl is already down, it won't send it down or up, but just use the physical press instead. And, as it turns out, this doesn't matter at all.

The glaringly obvious problem: clipwait. Your original script, without blind (but including the strReplace()), works 100% of the time. The problem is when clipwait is waiting, but doesn't get any content. If you use your script and have nothing selected when you press the hotkey, clipwait will wait indefinitely for the clipboard to contain contents. Pressing the hotkey again will not terminate the logical thread. So, clipwait needs a timeout.

Code: Select all

^u::  
clipboard=
    Send ^x ; Added blind
ClipWait,1
if(!clipboard)
    return
StringUpper, Clipboard, Clipboard          ; Convert text to upper

SetKeyDelay, 90
Send % strReplace(Clipboard,"`r") ; Added removal of return carriage
RETURN

This is confirmed by listlines.

[Nixcalo]

Nope, Masonjar13, I am sorry to say that NONE of the scripts included here change anything. Your suggestion does the same as it used to, it ramdomly capitalizes some of the strings and not others. And sometimes it gobbles letters. And sometimes if accesses menu options as if pressing Alt-something-.
A note, though, while I recognize the "problem" with the infinite Clipwait, I NEVER used the script having nothing selected. So that was never the particular issue, but thank you for the advice.

And your assertion that my original script works 100% of the time... well, it did not, that is why I posted! I would say it works over 70% the time. And the other 30%, it capitalizes the letters the heck of the system wants. And each time is different! (of course, there are a certain limit of possibilities!!!)

So nope, nothing changes anything. If want to capitalize
low pressure condition
I get in three consecutive attempts:
LOw OIL PRESSURE CONDITION
LOW Oil PRESSURE CONDITION
Low OIL PRESSURE CONDITION

A funny thing I just discovered that has me puzzled and makes me thing there is a real problem with this implementation. If I select AGAIN the same text I just partly capitalized, it will actually lowercase some letters! How absurd is that? I am using this same routing in LOW OIL PRESSURE CONDITION and it writes LOw OIL PRESSURE CONDITION!!!! How damn crazy is that????? It actually wrote "w" in lowercase when it was in upper and I just called the StringUpper function!!!!!!!!!!

No, something must be broken here. Any insight? Any developer? Anyone? Nothing proposed seem to help

[guest3456]

maybe try the solution in this thread:

https://autohotkey.com/board/topic/1118 ... -function/

[lexikos]

Regarding random (un)capitalization, this problem is inherent to the method of automation you are using; emulating keyboard input.

It will probably help to use the {Text} mode added in v1.1.27, as it does not rely on the Shift key state to produce the correct characters. (Although it uses the same OS functions used to emulate keyboard input, it really does something else; it instructs the OS to send a stream of messages with specific character codes, instead of key codes. If and when the target application passes the messages through the system's default processing, they are converted to keyboard messages for consumption by the application.)

For %clipboard% specifically, I would suggest not sending it at all. It is generally much more reliable to simply paste it.

Code: Select all

Send ^v

[Masonjar13]

It is generally much more reliable to simply paste it.

While that is correct, I just want to note that some applications do not allow native pasting (either blocks ^v or the output is very broken, only containing a few characters). I've had this happen with games and virtual environments such as emulators, as well as any console window prior to W10 (which introduced native pasting), for which I use an alternate paste hotkey which just [event] sends the clipboard. I forgot about {text} though, that should be greatly helpful!

[Helgef]

keys getting stuck

You might want to consider to install the keyboard hook. See #HotkeyModifierTimeout.

It uses {LCtrl Up} to avoid the modifier key issue

Code: Select all

Send {LCtrl Up}^x

That will not stop ahk from pushing it back down after the send.
Edit:

That will not stop ahk from pushing it back down after the send.

Maybe it is not relevant since there is no need for AHK to release (and then push down) ctrl since it is supposed to be down . But still, I do not think {LCtrl Up} before ^x does anything useful.

---

Code: Select all

ClipWait,1
if(!clipboard)
    return

Timeout is good, but to determine if the clipboard was set, check errorlevel instead. Eg,

Code: Select all

if errorlevel
	return

---

Additionally, if you still do not want to paste, i.e., send ^v, you might want to change StringUpper, Clipboard, Clipboard to StringUpper, var, Clipboard, and then send % var.

Cheers.

[Masonjar13]

I did try using the keyboard hook, but saw no difference, since I wasn't encountering the same issue. Perhaps it will work for him.

Here's what I'm gathering to be an optimal script for OP:

Code: Select all

#singleInstance force
#noEnv
setKeyDelay, 90

$^u::  
clipboard:=
send {blind}^x
clipWait,1
if(errorLevel)
    return
stringUpper,strVar,clipboard
send % "{text}" . strReplace(strVar,"`r")
return

Or if you want to retain what was on the clipboard prior to the hotkey:

Code: Select all

#singleInstance force
#noEnv
setKeyDelay, 90

$^u::  
clipped:=clipboardAll
clipboard:=
send {blind}^x
clipWait,1
if(errorLevel)
    return
stringUpper,strVar,clipboard
send % "{text}" . strReplace(strVar,"`r")
clipboard:=clipped
return

[Nixcalo]

I am sorry to be so blunt, but if something as EASY and BASIC as copypasting is creating such trouble, and one has to design such incredibly complicated scripts with errorLevels, {blind} and abstruse commands, damn it, I fear to think what might happen with more complicated designs and I believe that, even supposedly powerful, this Autohotkey is faulty at its core. :(:( This should NOT happen.

[gregster]

I am sorry to be so blunt, but if something as EASY and BASIC as copypasting is creating such trouble, and one has to design such incredibly complicated scripts with errorLevels, {blind} and abstruse commands, damn it, I fear to think what might happen with more complicated designs and I believe that, even supposedly powerful, this Autohotkey is faulty at its core. :(:( This should NOT happen.

The good thing is that AHK is open source. Feel free to suggest code improvements, if you have special insights... Where are all the "easier" alternatives with the same degree of flexibility?

[Xtra]

Autohotkey is faulty at its core.

I disagree.

This example i can not break it no matter how fast i use it.

Code: Select all

#NoEnv
/*
HiLiGhT aLl Of ThIs TeXt AnD pReSs CtRl U
low oil pressure condition
LOw OIL PRESSURE CONDITION 
LOW Oil PRESSURE CONDITION
Low OIL PRESSURE CONDITION
I WANT ALL OF thIS TO BE IN UPPERCASE
Diagnóstico
*/
^u::
    KeyWait, Ctrl
    KeyWait, u
    Send, {Ctrl Down}x{Ctrl Up}
    ClipWait, 1
    if (ErrorLevel)
        return
    Clipboard := Format("{:U}", Clipboard)
    ClipWait, 1
    if (ErrorLevel)
        return
    Send, {Ctrl Down}v{Ctrl Up}
return

HTH

[Masonjar13]

Being ignorant is not the same as being "blunt." If you think a mere 13 lines of code is overly complicated and makes a language "faulty," feel free to try writing the same in any other language. The core problem here is you don't understand how basic procedural coding works, which I certainly don't fault you, or anyone else who doesn't, for. I will fault you for, as I stated, being ignorant as to blame that which you don't understand, rather than trying to actually understand it.

What you need to understand is the fundamental difference between how a human interacts with software and how software interacts with software. Both cases are dependent on both the human and software in question, but to generalize: a human will interact with software at a superficial level, while software is significantly more useful and efficient operating at a more direct level. Commands and functions in languages that act to interact on behalf of a human will be flawed and inconsistent across different software interfaces, but also, you can make it work between such different software, which gives it its value. On the more direct side, you can post text directly into the memory of another process if you so choose, but this requires understanding how the software works more precisely. This is a more "guaranteed" approach, while the former is likely to be hit-or-miss, situation depending.

To simplify all that for you: copying and pasting data was designed for direct human interaction. Our brains can accommodate for different interfaces almost instantaneously. Software must be told how to interact with specific interfaces, as they don't all work the same. If it were so easy, developers wouldn't be so highly in demand.

You've had more help than I believe you're deserving of with your attitude, so I will leave this here. If you decide you'd like to be more receptive to learning, by all means, I thoroughly encourage you to do so; this site has a plethora of content to tantalize your neurons.

[Nixcalo]

Well, Masonjar13. First of all, I don't know what my attitude is. I believe that, while Autohotkey is undoubtedly useful, the fact of having to replicate a simple human interaction in a way that creates a lot of problems, creates random behaviours and, in general, makes something that must be simple be quite the opposite, makes me think that something is wrong at that language's core. If you have a language in which you try to print a single sentence, such as the famous "Hello world" and you have to start using Error Levels, subroutines, obscure {Text} or {Blind} parameters that were not present just 6 months ago because the output will be different depending on the operating system status, the number of active processes or whatever internal mistery, it seems something is wrong somewhere. When you say that copying and pasting data was designed for direct human intervention...this is NOT low level assembler, for God's sake, and I am quite certain that Visual Basic, C++ or Delphi manage these quite well.

So you are talking about my attitude for stating my opinion. I am not saying Autohotkey is crap. I am not saying that you are a bunch of freaks. On the contrary, I believe the software is a great piece of work, the Help system is INCREDIBLY detailed and the community here is amazingly kind, dedicated and supportive. But I DO say that whatever your complicated explanation might mean, a software should, as contemporaty as this, in this age (not 1980), make things easily and not randomly. I am not saying that Autohotkey is faulty because writing a 13 line code is complicated. I am saying that perhaps Autohotkey is faulty as its core because for something that apparently should be handled perfectly well and easily (sending a Control X and then sending a Control V, not rocket science, and something other languages do perfectly) , not just 13 lines are necessary, it's just that 4 or 5 different users have made their different contributions, each of them trying new things, and none of them working IS WHAT seems FAULTY. If I asked 4-5 people in any language to write a short script doing this, the appearance of each script might be alike or different depending on the complexity, but I am sure most would get the job done. Doesn' tseem to be this key, and some users confess they have the same random behaviour. Random behaviour, in any language, seems bad news.

It has nothing to do with having a million lines code. IT's just about doing a process that should be easy and straighforward and error free complicated (just pressing Control X, capitalizing and then pressing Control V), full of errors, mysteriously random and obstruse, and not even finding the key to doing it (as you can see, there are like 5 attempts here).

You may justify by saying that I don't know how it works, that there are many parameters to be accounted for, etc etc. and you are probably right, but shouldn't the software be the one accounting for them? If I press copy and paste in Windows, users don't really need to know how complex or easy is to copy and paste a sentence... they tend to expect it to WORK, not to work randomly or not at all, or sometimes and sometimes not, or depending on whether there are some processes active. And in principle, my initial code SHOULD work, the command for sending a key is SEND, the command for changing to uppercase is StringUpper, etc. Straightforward!!

So, when I am saying that Autohotkey is perhaps faulty at its core, I am not critizing the community. I am just PERHAPS pointing out that PERHAPS the sofware should treat these interactions at a different level, more user-oriented and less system-oriented? Perhaps the software itself should ensure no other processes get in the way at some internal level? Perhaps the software should treat hotkeys and user inputs differently?

Of course, that's something to debate. And when I meant faulty as its core, I did not want to imply the software is rubbish or it's all wrong, I apologize if I gave that impression. I am just saying that, perhaps as this level, the treatment of key presses or some keyboards commands can be done in a more reliable way because somewhere in the code, the way to detect those is creaeting this problems.

After all, this is how bugs are found. One finds something that should happen, and it does not. If you are doing Send ^x, and then Click 22, 20 and then Send ^v and it does not work, and the solution is to start making the code more complex.. well, perhaps it SHOULD work and that more complex code could be made internally. Saying that my attitude is not the best is unfair, in my opinion. I think you took it I said it was crap, which definitely would be a lack of respect (and a big lie!).

As a final point, you can check that other users have this problem, so the problem EXISTS. It may the user's, but it may be the software's.

So don't be offended, Masonjar13, when I say that autohotkey might be faulty if such a simple script that such random behaviours. You just implied I am ignorant, and I am not offended (because that's most definitely true, among other things! )