True in most cases. But i meant pauses in general, not a specific Pause instruction. 
I cut my teeth on a computer system that used the wonderfully named Panic assembly language. It was part of the air defence system at Staxton Wold, and rather like the old PDP-8 you had to toggle in the boot loader to load a paper tape to enable the teletype to start writing code. To quote the Four Yorkshiremen sketch “You tell the young ones today and they won’t believe you!” 
1 Like
I don’t know if this is exactly what you’re after, or if you have or want to have the MBS plugins, but there is a DelayMBS() method.
1 Like
That is a very diplomatic way of putting it. Well done.
To my mind asynchronous problems need asynchronous solutions and synchronous problems need synchronous solutions. (Even if advocates of one highly abstracted programming language do not recognise it.)
A 10ms pause is 1/4 of a frame at 25Hz. Why would anyone be concerned about locking the GUI?
function ShortWait(millis as integer)
var now as integer
var start as integer = system.microseconds / 1000
do
now = system.microseconds / 1000
loop until now - start > millis
end functionWhy loop the CPU, especially given that thread.SleepCurrent() is available.
Why not?
Let me put that another way. What is the tangible benefit of thread.sleepCurrent in this use case. Not trying to say there is not one.
Energy consumption, battery drain, thermal effects. Many good reasons.
I like that you found reasons. The delay being tens of milliseconds and the hysteresis of the things you mention being nearer to minutes. I would argue they are not especially good reasons.
One line of code instead of five?
1 Like
Your users may disagree. Any app that periodically consumed 100% of a CPU while apparently doing nothing is automatically suspicious.
Besides - even if it only saves a little energy - why not? Isn’t that worth it for such a tiny code change?
1 Like
Needing a synchronous delay of 100ms or less pretty much discounts humans being involved in that particular interaction. I attempted to capture the 100% CPU use with Resource Monitor but needed a delay of several seconds before it registered at all.
I don’t accept it saves any energy. I think at 100ms or less the difference in energy consumption is going to be indistinguishable amongst the noise floor.
fault tolerance. You may not be the one to abuse such feature and run in a loop for example, but anotherone may do that and have lot’s of issues. If one puts your requested answer in the first post, then many people (newbies mostly) will have issues caused by the answer on the forums.
I believe you have enough answers to your question by now.
Or mark it for advanced users?
I’m not saying anything is wrong or right but if you focus on impact of new users then I see no reason to hide this discussion just maybe mark as advanced/not recommended ?
What if someone was looking exactly for what @Matthew_Stevens described?
@TimStreater My only reason for using a loop is familiarity - I know it works. As I mentioned, I’m not going to fret about blocking for a 100ms or less so had no reason to look for an event driven alternative. I am open to there being a better way but would like to hear how it is better before refactoring.
Turns out there is a good reason to use a CPU loop. thread.SleepCurrent() simply isn’t very accurate in the tens, or even hundreds, of milliseconds range. Returning before the requested delay has expired is strictly ‘verboten’ in many machine comms protocols and a potential source of difficult to isolate bugs when it happens.
Microseconds
Sleep Wait
96,574 100,001
96,834 100,001
101,231 100,001
108,381 100,001
112,529 100,001
109,577 100,001
110,638 100,001
//button1.action
const DELAY_MILLIS as int64 = 100
var now as int64, start As int64, stop as int64
var resultSleep as string, resultWait as string
//sleep
start = System.Microseconds
Thread.SleepCurrent(DELAY_MILLIS)
resultSleep = Format(system.Microseconds - start, "###,###")
//wait
start = System.Microseconds
stop = start + (DELAY_MILLIS * 1000)
do
now = system.Microseconds
loop until now > stop
resultWait = Format(system.Microseconds - start, "###,###")
var results() as string = array(resultSleep, resultWait)
ListBox1.AddRow(results)Well Xojo still isn’t designed that way. Don’t use App.DoEvents unless you know what you are doing it’s not actually delaying only! Sp not meant for the OP s question.
Are you running Windows? And your CPU loop delay will need to be tuned for your processor freqeuncy, and so mayl change on another CPU.
I have tried it on Windows and Mac. thread.sleepcurrent is better on a Mac but still no where near as accurate as the loop, and still sometimes returns before the requested delay time has expired.
Why would I need to tune the loop? A microsecond on one CPU is much the same as any other.
Who would have thought that a question like “how do I do a sleep(100) in Xojo?” would yield almost 40 posts filled with so much confusion?
Please, just mark the post Problem with the lack of a simple Delay() or Sleep() method - #4 by TimStreater as the answer and let’s move on.
3 Likes
If you think you’ve found a bug, report the issue with the test sample, please: https://xojo.com/issues
What’s wrong with having a discussion? Is there a forum storage limitation? Thanks to @Matthew_Stevens we now have quantification of variations in thread.sleep timing that we wouldn’t have if we’d “moved on”. Information is good.
3 Likes