AutoIt needs.. sleep? :p

[Schoening]

Hey, so i just started yesterday with AutoIt and found that awesome beginner tutorial on the site

I made a script:

Send("{w}")

MouseClick("left")

Send("{tab}")

Send("{w}")

MouseClick("left")

Send("{tab}")

But the script did not work propperly.. So i changed it to this:

Send("{w}")

MouseClick("left")

Send("{tab}")

Sleep(1)

Send("{w}")

MouseClick("left")

Send("{tab}")

And it worked smooth.. Was this because the program i was running it in needed 1 Mil. Sec. to respond?

Sorry that i can't be better to describe myself

[Melba23]

Schoening,

Welcome to the AutoIt forum.

As you discovered , apps often need a short pause between Send commands to give them time to react. But there is no point in using a Sleep of less than 10ms - AutoIt treats them all the same as the API function it uses to pause itself has a minimum level of about that value (there are special cases like Sleep(0), but we will leave them until later.

M23

[Schoening]

But it works this way, and does not work without the Sleep(). So you are just saying that i should put sleep up to (10) ? I can't see the difference tbh but that's perhaps just because my eyes can't follow 1- 10 milliseconds

[Melba23]

Schoening,

As I said above, apps receiving multiple Send commands often require an intermediate Sleep to allow them to react. What I explained was that it makes no difference if you use Sleep(1) or Sleep(10) - AutoIt will give you the minimum sleep possible in either case.

M23

[Schoening]

ahh ! thx

[kylomas]

M23,

Care to expand on the sleep(0) comment??

kylomas

[Melba23]

kylomas,

As far as I understand it, using Sleep(0) tells the OS that the app is ready to give up its next timeshare on the CPU. If the CPU is busy then this could be a significant delay (in computer terms) - if the CPU is pretty much idle then it could be an almost instantaneous pause. There is probably more to it - but you will have to wait for a real nerd to come along and explain further (which comment will probably prevent anyone else from doing so!).

Of interest, Jon coded GUIGetMsg and TrayGetMsg in a similar manner - busy CPU means about 10ms delay; idling CPU means only just enough delay to give the CPU a break.

M23

[kylomas]

M23,

Thanks, sounds like you are describing preemptive VS. cooperative dispatching (no, not real nerd, trying to make transition from big iron to little iron OS's).

kylomas

[Beege]

Schoening, If i need a delay in the range of 1 to 10 I use sleep function from kernel dll. Heres quick example:

;Open handle to kernel making call to sleep as fast as possible
$hKernel = DllOpen('kernel32.dll')
;register function that will close handle one exit
OnAutoItExitRegister('_CloseHandles')

$hTime = TimerInit()
_Sleep(1)
ConsoleWrite('Sleep(1) = ' & TimerDiff($hTime) & @LF)

$hTime = TimerInit()
_Sleep(2)
ConsoleWrite('Sleep(2) = ' & TimerDiff($hTime) & @LF)

$hTime = TimerInit()
_Sleep(3)
ConsoleWrite('Sleep(3) = ' & TimerDiff($hTime) & @LF)

$hTime = TimerInit()
_Sleep(0)
ConsoleWrite('Sleep(0) = ' & TimerDiff($hTime) & @LF)

Func _Sleep($iMs)
     DllCall($hKernel, 'none', 'Sleep', 'dword', $iMs)
EndFunc
Func _CloseHandles()
     DllClose($hKernel)
EndFunc

My results were

Sleep(1) = 1.05511285324879
Sleep(2) = 1.9529418029077
Sleep(3) = 2.99126132270029
Sleep(0) = 0.0307195124198989

Also from the msdn:

If you specify 0 milliseconds, the thread will relinquish the remainder of its time slice but remain ready. Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses.

Edited January 10, 2012 by Beege

[kylomas]

Beege,

Thanks, this was curiousity only. When I read something that I don't understand (as in

M23's comment) then I ask a question, often to the annoyance of others!

kylomas

[Beege]

Sorry thats my bad. When I replied, I looked at post #7 and thought you were the OP. Ill edit that.