I say again that it should be removed immediately from targets where it should not be used. I’ll file Feedback later and post the link here.
Why? If you don’t like it, think it is evil, etc… don’t use it…
The same arguments that are presented for GOTO/GOSUB apply here.
The comparison is faulty because those won’t lead to crashes. They are strongly discouraged, but can still be used safely. App.DoEvents cannot, but a new user will not know that.
Kem is right. There is never a legitimate usage in Desktop or Web apps.
How about just make it a no-op in GUI apps? For internal event use, change its name to PrivDoEvents and scope to private. Call it a bug fix. When it doesn’t do anything, people will stop using it inappropriately.
We got it. Stop now, please.
I liken this to Threads accessing the UI. Always a bad idea but it wasn’t until recently that Xojo enforced it.
App.DoEvents is similar in that it leads to unpredictable results and spurious, random crashes that were blamed on Xojo when it was the developer using an API that was meant for different purposes.
If I was a betting person (I’m not, Vegas showed that) I would say that it might get an exception in a desktop or web application.
Well, I use it sometimes and never had any issues with it.
So please do not remove app.doevents
This is roughly equivalent to saying “I’ve deliberately jumped in front of buses many times despite the obvious danger & advice to avoid this and never been seriously hurt so I will continue to do so”. One day it will hurt very badly and all the people near you can say is “we told you so”.
It’s more amazing that you haven’t been hurt up until now.
As said … we get it. Stop about it now. Just don’t remove it.
As I said at my talk, although I don’t have any inside information, I’d bet the Xojo Framework will not have an equivalent. You’d be wise to fix your code now.
Bummer … that would be a VERY hard pill to swallow. 
I don’t see why. There are pretty easy alternatives.
Christof, think of it as a vaccine against future disease. The needle hurts today, but you never get the disease. Then, realize that your code is already infected with the virus that causes the disease, and that it’s just a matter of time… unless you get the vaccine.
Removing app.doevents will hurt A LOT of users.
Anyhow, its clear users not always get what they want. 
And I still see no reason to really remove app.doevents (yes I know the drawbacks and its bad code practice - its been told 1000 times).
[quote=75247:@Christoph De Vocht]Removing app.doevents will hurt A LOT of users.
Anyhow, its clear users not always get what they want.
And I still see no reason to really remove app.doevents (yes I know the drawbacks and its bad code practice - its been told 1000 times).[/quote]
We try to give you ways to write better code & not ways to shoot yourself in the foot
DoEvents is a shoot yourself in the foot tool
But first it would have to be deprecated before it would be removed since that is the normal process and we REALLY try to stick to that unless there is some really exceptional reason not to
And you also shoot users when they use it.
But I do understand it now … we have no input in this. So just remove it.
[quote=75249:@Christoph De Vocht]And you also shoot users when they use it.
[/quote]
If we “shot you” we’d probably throw an exception - thats as close to shooting you as we can get.
But we don’t.
The bugs it causes in your apps are then reported to us as bugs in the language despite them being self induced.
They often take a lot of time to track back to the use of doevents.
We’d deprecate it first
Well, if you ever do decide to depreciate this… at least leave it alone in Console/Service applications. I can see it being an issue at times (mostly avoidable) in GUI-specific applications; however, it has its definite purposes in other applications.
Suddenly all this energy on this topic from XDC attendees … What did they do… put something in the water or experiment with new mind control technology? 