Problem with the lack of a simple Delay() or Sleep() method

I need to implement a short delay between two lines of code. In just about every other language this is simple, but in Xojo Desktop it isn’t. I have searched the forum and Google and there are suggestions that I should put the code in a thread and sleep the thread - impractical, use App.Sleep() - doesn’t exist, Application.SleepCurrentThread() - doesn’t exist.

Any ideas on how to put a simple delay like below -

Do this line of code
Delay(100) or Sleep(100)
Now Do This

Thanks

no you don’t need a delay.
Xojo is event based, design your code otherwise.

Or make a Sub:
Sub CallMeLater

and do your code:

DoThis()
Timer.CallLater 10, AddressOf CallMeLater // 10 ms later it will call CallMeLater

in Callmelater you can do as you like…

Or use a timer, or thread (but that complicates more).
A timer subclass would give you more options.

3 Likes

Sorry but the “no you don’t need a delay” is rather brusque isn’t it? I do actually need a delay, and timers and threads are overkill. Making a coder jump through hoops just to have time between two lines of code to allow a process to complete is hardly user friendly.
It appears that there were Sleep functions but they do not appear to be available in the latest Xojo Desktop, unless I am missing something.

Try:

thread.SleepCurrent (1000)

It will sleep you 1 sec. Of course, it will block your UI for that time too, unless you’re doing it in a thread.

Thanks Tim, that is the one that I was missing.

I’m reading “i need a way to freeze my app, or at least to make it not respond to user input. how?
I am a bit affraid to ask “why???” but I’m really curious at the same moment. :wink:

2 Likes

Not really.

Why events are preferred over pauses in event-based programming languages

In event-based programming languages, code is executed in response to events. Events can be generated by user input, hardware interrupts, or other software components. When an event occurs, the appropriate code is executed to handle the event.

There are two main reasons why events are preferred over pauses in event-based programming languages.

1. Events are more efficient

When a program pauses, the CPU is not doing any useful work. This can waste CPU cycles and lead to performance problems. Events, on the other hand, do not require the CPU to pause. The CPU can continue to execute other code while waiting for an event to occur.

2. Events are more flexible

Pauses are a fixed-length delay. The program will always pause for the same amount of time, regardless of the circumstances. Events, on the other hand, can be triggered at any time. This makes them more flexible and allows the program to respond to events in a timely manner.

Here are some specific examples of how events are used in event-based programming languages:

  • In a graphical user interface (GUI), events are used to handle user input, such as mouse clicks and key presses.
  • In a real-time system, events are used to respond to changes in the environment, such as sensor data or network traffic.
  • In a web application, events are used to handle user interactions, such as clicks on buttons or links.

In general, events are a more efficient and flexible way to pause the execution of code in event-based programming languages.

Additional benefits of using events

In addition to the two main reasons listed above, events also offer the following benefits:

  • Decoupling: Events decouple the code that generates the event from the code that handles the event. This makes the code more modular and easier to maintain.
  • Reusability: Events can be reused by multiple components of a program. This makes the code more efficient and reusable.
  • Scalability: Events can be easily scaled to handle large numbers of concurrent events. This makes them well-suited for applications that need to handle a lot of user input or other events.
2 Likes

Xojo does not run like an Arduino/c app. It’s different!
You don’t want to freeze your GUI in a Xojo Desktop app you don’t freeze your app using a delay!

Just use a timer or thread.sleep or something that compares but don’t do it the way you asked streight in the gui (main thread).

Go ahead App.DoEvents(10) will cause you alot of pain but there you go.
This will forever hunt you in the future, it will delay for 10 milliseconds and give you a main loop in the main loop since you are in a event based application and there is no actual Sleep.

Since you say overkill? if you have 2 lines of code, then your pc will be overkill for the app.
Just use a Timer or Thread or the Timer.CallLater(10, AddressOf myMethod) and you’ll be happy…

Guys, I’ve been a programmer/engineer for over 60 years and I am quite aware of everything that has been said about event driven programming. All I am trying to do is put a small delay of about 5 to 10 mS between two function calls to allow a hardware port to settle. These calls are scattered about the program and all are different in some way making it inconvenient to wrap them or make a class or any other such shenanigans. My question was really just to see if I had missed something in Xojo as I mostly program C/C++/CSharp and have only been using Xojo for a short while. I do appreciate the help everyone has provided.

This forum is an interesting place. It has grown on me over the years, but one thing that takes a little getting used to is needing to justify one’s approach to the crowd. I have come to discover that it comes from a place of caring. People genuinely want to help, and there are a lot of folks who actually need the guidance in doing things the “proper” way (“proper” is in quotes because it’s such a subjective term in this field). Once a few people have chimed in on the accepted approach for the language, I think there are OPs who get value out of that.

There are always those of us who have fringe cases though, like allowing time for a hardware port to settle. There are also times (speaking from experience) when I’ve already structured my whole project based on the “improper” way of doing things but getting it done quickly / on-deadline is more important than refactoring code for hours to do it “properly.” Yes, that can mean the buildup of technical debt, but hey, that’s next year’s problem and maybe I’ll be dead by then. :laughing:

In any case, my point is that OPs can sometimes feel attacked in these types of threads but I’ve come to realize that’s never (well, rarely) the intent.

Best of luck with your project, cheers.

6 Likes

I hope so on your side you see it this way since there is no harm intended. Just be noted, this has been asked a quadrillion times. you could have looked it up. But hey there truely is no such thing in xojo as a in-between-code-true-delay. The only actual way is to transfer your code to be called lateter (in an event based way).

Anyway that’s all one could do for another and the next people to read is, be warned.

https://forum.xojo.com/search?q=delay

1 Like

One other way may be to build a console application and put App.DoEvents(…delay in ms here…) then report back if your re done, but again you have “overkill” …
There is so many ways to fix your issue, but not in your requested way as in doOne-delay10ms-doTo in a single editor view other than a console application or thread for that matter.

Christian - indeed, thanks for the message. As I said at the end of mine I do appreciate everyones help, but as you most eloquently put it 'when you are up to your arse in a Alligators it is important to remember the objective was to drain the swamp!", I may have paraphrased it a little.
The code is written and working fine with the slight exception that sometimes the RP2040W’s on the other end need a bit more time. A re-write is not really feasible so ‘Quick and dirty’ was the intention. It ain’t pretty, but I try not to look at it!

1 Like

DerkJ - Interestingly I did do a lot of research before posting here, I even tried ChatGPT as a last resort. The problem I bumped up against was that all of the suggestions seemed to use methods based around either App or Application, but when I tried to use them they were not present. Hence my wondering if I had missed something. Had Xojo moved them?

I was a Xojo consultant for 20 years, did a bunch of training videos (no longer available) so I’m no newbie. My advice for developers new to Xojo is to not try to force Xojo to do things like . It will almost always come back to bite you later because Xojo is not and does things different (for better or worse).

I think that’s why some of the responses have been brusque. The people responding have either been bitten by the exact thing you’re proposing or have seen enough to know why it’s not ideal. Either way, we’re trying to save you some heartache later on.

Using a timer or CallLater is the preferred way. But you do you. We’re just trying to help.

9 Likes

My problem is that I am having to use Xojo because the program needs to run on both Mac, Windows and possibly iPhone and the thought of having multiple completely different codebases was enough to give anyone conniptions. The Mac and Windows code is done, and working 99%, with just one small detail to iron out so forgive me if I tried to find the easy way out. Pride prevented from implementing a for/next time wasting loop hence my question. Still, all’s well that ends well as the software and hardware are now working harmoniously together. Now to 3D print a load of cases and find a whole bunch of new problems :grinning:

A sleep() is a fixed length delay. A pause() will pause the thread indefinitely, and it’s up to you to organise that an event handler does a resume() on the thread so it continues. Such a resume() is appropriate when an event handler for timeout, error, or datavailable fires. The thread then reacts according to which event fired.

OK you beat me by a couple of years. First bit of code I wrote was to extract square roots by Newton’s method. On a mmachine with 4k words of store and only a paper tape reader/punch for I/O.

If you’re tuning the delays for different plaforms, don’t forget that you can use conditional compilation for that or define a constant in the IDE which has platform-dependent values.