There is one case where it seems it might be OK and that is so niche that 99.999% of people will never be in this situation.
And it can be replaced with a thread - hence why I’m not suggesting it be used at all.
DoEvents is used in places it shouldn’t be for reasons that, when you get right down to it, are exactly why you’d use a thread.
Threads just seem harder so people avoid them.
Thom and I have said “Do Events causes one iteration of the event loop to run which can cause reentrancy problems”
See https://forum.xojo.com/10498-making-the-case-to-remove-app-doevents/34#p75392
DoEvents is NOT the same since - well Xojo is Xojo and VB is/was VB. Different tools different goals & different underpinnings.
Completely different under the hood so the only reason it’s used as much as it is is precisely because of this bad assumption that “Hey its named the same so it must behave the same!”
It doesn’t.
As Aaron wrote nearly 6 years ago
[i]former REAL Software engineer, Mars Saxman, explained it in the most eloquent way:
DoEvents is not just a yield function. It does yield to other threads, but it also runs the event loop. If you call it from threads other than the main thread, you will end up splitting your main event loop across multiple threads. If you are unlucky, this will not cause any problems right away, and you will think your program works. Then one of your users will manage to get the timing just right and your app will wind itself up with one DoEvents call inside another until your stack overflows.
[/i]
Evil because your app is OK until its not and then you have no idea why or how to fix it.
So using it can cause data to be received out of order (apparently) as you can get
Serial1.DataAvailable > DoEvents > Serial1.DataAvailable > DoEvents
and the second data available can complete before the first
The same hold true for many other cases like timers or anything else that gets tickled from the main event loop.