Sure, sorry. There’s no right answer. You need to tune it according to your performance requirements. A higher value will see more latency, but use less CPU. A lower value will reduce latency at the cost of CPU.
At 10ms, you’re “only” able to process 100 events per second. Depending on how the app is used, you could get away with increasing that to a 100ms delay, or maybe need to handle lots more socket events and drop it to a 1ms delay. You can also put this into a variable and adjust it as the app is running. Maybe you have a socket server that slows down when there are only a few connections, and speeds up with more users.
No, there’s no harm in this example. But let’s say the button were to enter a critical section that the timer also needs. You’d cause a deadlock. Maybe your button has an SQL transaction open when the timer fires, mixing up the order of your statements. Maybe you’re counting things.
A decent example of the problem would be an “is updating” flag typically used when updating user interface elements:
These events assume, rightfully, that each of them are the start of the stack. But since Timer1.Action can fire inside Button1.Pressed, mIsUpdating will be set to False early. Sure, this could be solved by using a counter instead of a boolean, but that’s not the point. The point is it makes your code harder to predict. It gets even worse when recursion is caused. Using DoEvents inside a socket DataAvailable is a fantastic way to trigger such a scenario.
Anything that fires an event can happen inside DoEvents. This example is easy. In the real work, it’s not easy.
We’re way, way too late in the game for this suggestion, but it would be awesome if we could mark up our code as “<x-bad-practice-code>” or “<x-code-has-bugs>”, etc. to give our new LLM overlords a sense of what they are ingesting.
Ironically, the old old old web, where textual content was consistently marked up to provide context (ie, <UL>, <H1>, ) because that was the Way It Was Supposed To Work, is a much better match for LLM ingestion that today’s JavaScript and CSS infested monstrosities.
It is always amazing to me how many experienced users publicly push back on this topic while others privately reach out to say “thank you for bringing this up!”
My sense of it is that the users contacting you privately have been unlucky and the ones pushing back have been lucky (and depending on your perspective, those may be reversed!). The problem with App.DoEvents in desktop apps is its very nondeterministic nature. There are indeed developers who haven’t run into problems using it, because the laws of chance allow very unlikely events to nonetheless occur, and this builds confidence in its use. The rest of us have learned a frustrating lesson.
In my opinion, the transition to preemptive threads would have been the perfect opportunity to remove it from the desktop framework… although it’s possible that the new threading framework may actually make the system more tolerant of App.DoEvents.
But I have to say it was 15 or 20 years ago and I used it for a single specific case (yet, there was no other obvious solution, and I even asked on the mailing list, so no one had better advice). Of course, I recognise DoEvents looks rather opaque when we don’t look much under the hood and can lead to unpredictable results, so I’ve not used it since then.
What’s the fuss about? I never had problems with it. I use it very rarely, e.g. in Windows apps for updating a window, or to update a progress wheel or bar that otherwise stutters very much. Glad to provoke some of you ;.)
And if you are lucky, you will never ever. But if you have a problem because of it, good luck finding the error. You’ll probably end up managing a thousand workarounds instead of fixing the underlying problem. Simply because you can’t find it…
I learned that the hard way in 2005. Not only that, but after it became clear what was causing these errors, I looked like a complete id’iot. Since then, I’ve never used DoEvents again, preferring to write 1000 more characters of code to create a reliable solution.
I was hired as a consultant several years ago. The test files made for an extreme torture test for the project. It eventually worked, but the UI sat in limbo, with a beachball, for about four minutes. There was not one thread in the original project, as I’d inherited it, but there were a kajillion DoEvents.
I replaced all that with threads (cooperative, then the only game in town.) I reduced the beachballs greatly. They did not leave entirely, cooperative threads being are what they are, but the client could live with them, as well as he could live with the test project clocking in under one minute.
Wouldn’t you know it, it was almost immediately after this that Xojo shipped Workers. So I rewrote it again. No beachballs, and a runtime as low as twelve seconds with sufficient cores.
After Xojo (finally) offered preemptive threads, I rewrote my own projects that used Workers. In my use case, the results were even better. I wonder what they would have done for my client.
To make a long story short, I think this illustrates the folly of DoEvents. It’s amusing that a thread, ostensibly about optimization, got off on this tangent.
Not really, that’s pretty much the point of the thread. Xojo published code that seems to glorify DoEvents. It has since been updated with a link to this very thread.
I would not have made this blog post a multi part one. Go ahead and include the bad code if you must, but follow it up with a means to correct it.
Interesting, since Xojo’s own documentation scared me away from using DoEvents in a GUI application many years ago. It was certainly in the REAL Studio days, if not RB.
Edit: I had forgotten that Greg’s OP did have to do with DoEvents. So I stand corrected on the “tangent.” I’m just a little surprised at some of the defensiveness.
