Random behavior in script. How do you know where Sleep commands are necessary?

[Nixcalo]

Hi everyone!

I have a script that has a random behaviour, where it should not. I suppose it's due to the fact that the script is too fast in some cases. I don't really know how Autohotkey processes the script from one line to another and whether it's supposed to wait for one line to be completed in order to process the rest, but it's a certain fact that, in some cases, Sleep commands are necessary to slow down, particularly when working with the ClipBoard and keypresses.

And I am sorry that my question has to be a little generic because my script is quite complex, it calls functions and functions within functions so it would be pointless to post it here. The question is... why is the behaviour random? I mean, what is the methodology for AHK to process lines successively and what commands are known to cause problems so Sleep commands are necessary? I mean, one always have to be careful with key presses and Clipboard operations, but what else?

I am asking because I have no idea why my script has a random behaviour. I think it is because some actions need time to be completed (for example, reading a long variable) and without a Sleep command, the script goes on without waiting for that variable to be populated... but in this particular case, I have no frigging idea where I should insert the Sleep commands, I have gone as far as inserting Sleep, 1000 commands after every line in my script, and the script continues doing silly things, so it must be a problem of the functions being called. But those functions are not mine, they are taken from this forum and they used to work...

And the script does things as silly as writing "Sleep, 1000" in the page where the cursor is instead of executing a real Sleep, 1000 command! Or for example, writing a literal MsgBox, %Variable% text instead of executing the MsgBox command and telling me the contents of %variable% in a box! It's crazy and driving me nuts! Sometimes the script results in some Chinese letters appearing after the cursor! And all it should do is extract the Text from an HTML code!

P.S. I would like to say that sometimes, but only sometimes, the script does as expected. Other results are writing chinese letters, or absolutely nothing, or writing parts of commands after the cursor (for example, if I have Send, %Var%, sometimes the script writes the literal "Send, %Var%" instead of writing the contents of "Var". It's crazy!

So any insight? How do you debug the script where such random errors occur and you know it must be because the script goes too far or the PC goes too slow? What is your experience about problematic issues that need slowing down? As I said, keypresses and clipboard operations, but if I perform a complex RegexReplace operation, will AHK end until the operation is finished to continue to the next line?

I am suspicious that AHK does not wait for some lines or functions to be finished in order to go on with the next line of the script, and that scrambles things. Could that be?

Thank you and sorry for the generic post.

EDIT: I am an idiot. The issue was solved with a simple ClipWait after a Send ^x command. But the issue remains, why not waiting for the ClipBoard to be populated can create random (and weird) effects? And what if no apparent Clipboard issue exists?

[boiler]

AHK scripts do not do random and weird things. It just may sometimes be difficult to identify the reason it is happening. Sometimes Sleep and other commands are necessary to have other commands execute in a timeframe or manner that is compatible with the environment they are operating in and programs they are interfacing with. AHK can’t inherently know the timing necessary to sync up with the things you want it to. You have to explicitly tell it, and that often entails having it wait for certain conditions to occur.

If you have a Sleep, 1000 command, AHK never sometimes randomly and accidentally sends that as text instead of executing the command. If it does so, it’s because there is something about the way your script is written. Of course I can’t give you more specifics without you sharing your script. Just know that computers/programs do what you tell them to do, not necessarily what you expect them to do.

[Nixcalo]

Ah Boiler, I wish you were right. But the fact remains that adding a ClipWait, .2 after a Send, ^x command changed the behaviour of my script drastically, to the point that the script stopped writing Chinese letters or pasting commands instead of executing them.

The script was simple enough: This uses the WinClip library to get text from HTML.

Code: Select all

^+q::
ClipBoard:=
SendInput, ^a
Sleep, 10
SendInput, ^x
; ClipWait, .2 ; THIS IS THE KEY, REMOVING THIS CREATES HAVOC!!
 Sleep, 10
PlainText := WinClip.GetText()
Sleep, 10
; MsgBox, %PlainText%
WinClip.Clear()
 SendInput, %PlainText%
Sleep, 10
Return

As I say in my post, removing that simple Clipwait command creates a nightmare of random results, from Chinese letters to weird things. If I remove the semicolon in the ; MsgBox, %PlainText%, I even saw "MsgBox, %PlainText%" where it should execute the SendInput, %PlainText% command. A mess.

[boiler]

You're saying that as if adding ClipWait is overcoming randomness of AHK. It's obviously an AHK command for a reason. It's there to deal with the time it takes for Windows to actually load the clipboard with its contents. The fact that Windows takes time to do so is not a failing of AHK. That's a reality of Windows and of computing in general. And the fact that sending ^c or ^x does not automatically trigger AHK to wait for the clipboard to be loaded before executing the next command is also not a failing of AHK. No one should want AHK to pause after sending certain key strokes before executing the next command because that would unnecessarily slow many scripts. And for those that need it to wait, there is the ClipWait command.

If anything, you just pointed out the foresight and strength of AHK, not a shortcoming and definitely not an inherent randomness.

[Nixcalo]

Ok, I'll change my reasoning.

Windows 10 is random and does weird things.

Sure you can't argue with that!

But it's certainly weird that the fact of not waiting for a Clipboard to fill does such weird things. Three consecutive attempts did three different things, each weirder than the last.

So how do you manage to debug script in order to check for the necessity of Sleep commands?¨How do you know when Sleep or ClipWait commands are necessary and where? Any special insight? Any debugging program or technique you use?

[boiler]

I would say that interfacing with another program (in this case the OS itself) can seem random, but it mostly has to do with the fact that the other programs were written for a human to interface with them, not another piece of software. So our script is basically trying to emulate a human, and we have to be cognizant of that when we write our code. The creators of Windows know that no human is going to copy something (either by pressing ^c or right-clicking and selecting Copy) and be ready to paste it within a few milliseconds. Windows is not doing anything wrong when it takes tens of milliseconds to populate the clipboard for its human users because they will not be pasting it any faster than that.

When we write scripts that interface with other programs, we have to understand that those programs are executing commands, and they take time, whether it's moving text, drawing a window, loading a web page, or whatever. It comes with the territory to realize that the timing between two programs has to be accounted for, especially when one program doesn't even realize that it's being interfaced with by another program, therefore there are no handshaking protocols in place or anything that would make it more foolproof.

There are different circumstances, such as when using COM to interface with objects from programs that have provided that interface. When a program has provided such an interface (an application programming interface, or API), it expects other programs to be interfacing with it and there is less that has to be dealt with to account for the differences between how a human and a piece of software would interact with it.

Knowing when to add Sleep, ClipWait, or other commands that help make the interface with other programs repeatable and reliable comes with experience. They are learned via trial and error and from the experiences of other programmers shared on forums like this one. The more you do it, the more you'll know in advance to be aware of those things and build code that accounts for them into your script.

[Nixcalo]

Thank you boiler, for your feedback. Indeed, you are the voice of reason and experience.

[RickC]

I tend to agree with @Nixcalo's assessment of Windows 10 but there's a reason. By comparison with Windows 7/8.x, Windows 10 does a lot more constant background processing, particularly logging but also registry accesses.

If you use Sysinternals/TechNet's free, portable Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) you'll see not hundreds nor even thousands but millions of entries in its activity logs within a very short time - far more than in previous versions of Windows.

Somehow all other processes, including AutoHotkey's script interpreting, have to find a space in amongst all this increased activity. The differences in timing from one 'script run' to the next of the very same AHK script may be fractional but, IMO, they do exist.

[boiler]

That’s exactly why you put things into your script to account for that. ClipWait and other approaches don’t count on processes taking a certain amount of time. They wait for certain things to be true before continuing, allowing for that time to vary. It’s when you code assuming that things happen either instantly or in a repeatable amount of time that you build in unreliability into your script.