# Re: Optimizing Xojo Code, Part 1: Getting Started **URL:** \ **Category:** General\ **Created:** [November 26, 2025, 11:40am UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096 "2025-11-26T11:40:21Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Greg\_O](https://forum.xojo.com/user_avatar/forum.xojo.com/greg_o/32/22785_2.png) [@Greg\_O](https://forum.xojo.com/u/Greg_O)\ **Post date:** [November 26, 2025, 11:40am UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/1 "2025-11-26T11:40:21Z")
In the recent blog post about optimizing code, it should have been highlighted how dangerous it is to use app.doevents in a desktop app. I can’t believe it’s not mentioned! For all you newbies, DoEvents is there because a **Console** app needs a way to create a run loop if it’s more than just a one-shot program. Otherwise, just doing a tight loop hangs the app. In Desktop apps, it makes debugging your app damn near impossible and opens you to ThreadAccessingUI exceptions. ---
**Author:** ![Jeremie\_L](https://forum.xojo.com/user_avatar/forum.xojo.com/jeremie_l/32/150_2.png) [@Jeremie\_L](https://forum.xojo.com/u/Jeremie_L)\ **Post date:** [November 26, 2025, 11:51am UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/2 "2025-11-26T11:51:41Z")
When using App.DoEvents in a **Console** app, is it better to use the default 10ms delay or increase that value? I believe this will depend on how the app is architectured, but the Xojo docs don’t give any indication. My use case is a Console app running the main routines in Threads with heavy use of URLConnection async calls. I have a simple While loop in App.Run that waits for a flag to be set: ```xojo While AllJobsCompleted = False App.DoEvents(200) // is it better to increase or decrease this value? Wend //The app is now ready to Quit ``` ---
**Author:** ![Arnaud\_N](https://forum.xojo.com/user_avatar/forum.xojo.com/arnaud_n/32/21824_2.png) [@Arnaud\_N](https://forum.xojo.com/u/Arnaud_N)\ **Post date:** [November 26, 2025, 8:42pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/3 "2025-11-26T20:42:22Z")
> [@Greg\_O](#): > > DoEvents is there because a **Console** app needs a way to create a run loop if it’s more than just a one-shot program. Otherwise, just doing a tight loop hangs the app. And yet DoEvents **is** available in desktop projects. ---
**Author:** ![ChristopheDV](https://forum.xojo.com/letter_avatar_proxy/v4/letter/c/59ef9b/32.png) [@ChristopheDV](https://forum.xojo.com/u/ChristopheDV)\ **Post date:** [November 26, 2025, 8:45pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/4 "2025-11-26T20:45:07Z")
Yes, and never remove that either! It is needed in situations. Period. ---
**Author:** ![Greg\_O](https://forum.xojo.com/user_avatar/forum.xojo.com/greg_o/32/22785_2.png) [@Greg\_O](https://forum.xojo.com/u/Greg_O)\ **Post date:** [November 27, 2025, 1:25am UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/5 "2025-11-27T01:25:15Z")
It’s there for legacy reasons, but it’s still not a good idea. ---
**Author:** ![Rick\_Araujo](https://forum.xojo.com/user_avatar/forum.xojo.com/rick_araujo/32/251_2.png) [@Rick\_Araujo](https://forum.xojo.com/u/Rick_Araujo)\ **Post date:** [November 27, 2025, 12:16pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/6 "2025-11-27T12:16:28Z")
The only moment I need a DoEvents() for a Desktop app, is during tests where I finish with DoEvents() Quit Because (Xojo bug? Or “As Designed”) seems to create a System.DebugLog() print queue that is not flushed at quit time and the contents are destroyed never being printed in the debug console window without the DoEvents() acting like a FlushPendingDebugLogs() Without DoEvents() to enable a “FlushPendingDebugLogs()” the tests fail to show the expected and real values. It truncates the prints. ---
**Author:** ![Thom\_McGrath](https://forum.xojo.com/user_avatar/forum.xojo.com/thom_mcgrath/32/192_2.png) [@Thom\_McGrath](https://forum.xojo.com/u/Thom_McGrath)\ **Post date:** [November 29, 2025, 8:21am UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/7 "2025-11-29T08:21:10Z")
> [@ChristopheDV](#): > > Yes, and never remove that either! It is needed in situations. Period. No, it isn’t. The **only** reason it hasn’t been removed is because the IDE used (or uses) it for the splash screen. This too is a bad design. It’s always a bad design, especially with regards to threading and even more so with preemptive threading. If you want to produce some bizarre stack traces, DoEvents will get you there. Any time you think you need it, you’re wrong. It may be annoying or downright hard to do it right, but DoEvents is simply not a substitute for proper concurrency. ---
**Author:** ![Arnaud\_N](https://forum.xojo.com/user_avatar/forum.xojo.com/arnaud_n/32/21824_2.png) [@Arnaud\_N](https://forum.xojo.com/u/Arnaud_N)\ **Post date:** [November 29, 2025, 10:09am UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/8 "2025-11-29T10:09:05Z")
We can never be certain of anything, can we? ---
**Author:** ![Rick\_Araujo](https://forum.xojo.com/user_avatar/forum.xojo.com/rick_araujo/32/251_2.png) [@Rick\_Araujo](https://forum.xojo.com/u/Rick_Araujo)\ **Post date:** [November 29, 2025, 11:58am UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/9 "2025-11-29T11:58:42Z")
You will disintegrate in flames 500.000 Km from the Sun. I’m sure of it. ---
**Author:** ![Thom\_McGrath](https://forum.xojo.com/user_avatar/forum.xojo.com/thom_mcgrath/32/192_2.png) [@Thom\_McGrath](https://forum.xojo.com/u/Thom_McGrath)\ **Post date:** [November 29, 2025, 1:14pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/11 "2025-11-29T13:14:17Z")
This is a silly thing to say. There’s plenty we can be certain about. If you throw a ball, you can be certain it’ll hit something. A wall, the ground, a person, whatever. It’s going to impact _something_. You know this because your experiences on this planet tells you as much. No sane person would argue otherwise. Likewise, what I’m saying about DoEvents comes from decades of experience with Xojo. I’ve seen the pitfalls first hand. I’ve made the mistakes. I’ve seen the stack traces of a timer action event that appears to run inside a database query. I don’t say this because I like to or I want to make your life more difficult. I say this because I have the experience to share. I want to help you be a better developer. You can lead a horse to water, but you can’t make it drink. ---
**Author:** ![Greg\_O](https://forum.xojo.com/user_avatar/forum.xojo.com/greg_o/32/22785_2.png) [@Greg\_O](https://forum.xojo.com/u/Greg_O)\ **Post date:** [November 29, 2025, 2:27pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/12 "2025-11-29T14:27:09Z")
To wrap this up, my intention was to point out that anything that Xojo publishes, whether it’s by one of the employees or by a guest contributor becomes part of the canon of best practices for Xojo. The problem here is that the use of DoEvents is definitely not a best practice and one could argue that it’s a worst practice for all intents and purposes. Since the AIs of the world are being trained on all things on the internet, this is going to be assimilated because it’s on an official Xojo site and users will unwittingly be getting code with it for years to come. Thom and I both have the experience of having worked at Xojo on the IDE and seeing all the bad that DoEvents can cause. Please, PLEASE don’t use it unless it’s an absolute last resort. ---
**Author:** ![ChristopheDV](https://forum.xojo.com/letter_avatar_proxy/v4/letter/c/59ef9b/32.png) [@ChristopheDV](https://forum.xojo.com/u/ChristopheDV)\ **Post date:** [November 29, 2025, 2:35pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/13 "2025-11-29T14:35:13Z")
> [@Thom\_McGrath](#): > > If you want to produce some bizarre stack traces, DoEvents will get you there. I use it in some apps and it would be extremely difficult (if almost impossible) to do without unless I put that code in threads which is, in my case, almost not doable due to cheer size of the project. I also never had any issues with it. It would be great if you provided us a project that show cases it can crash, do odd things, behave oddly, … in a **use case scenario**. That would be great. This has been asked several times in the past but no-one has ever provided such examples. ---
**Author:** ![Greg\_O](https://forum.xojo.com/user_avatar/forum.xojo.com/greg_o/32/22785_2.png) [@Greg\_O](https://forum.xojo.com/u/Greg_O)\ **Post date:** [November 29, 2025, 2:49pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/14 "2025-11-29T14:49:13Z")
Yeah and there’s a reason for that. DoEvents works great until it doesn’t. When it fails, it does so spectacularly. ---
**Author:** ![Tim\_Parnell](https://forum.xojo.com/user_avatar/forum.xojo.com/tim_parnell/32/161_2.png) [@Tim\_Parnell](https://forum.xojo.com/u/Tim_Parnell)\ **Post date:** [November 29, 2025, 2:58pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/15 "2025-11-29T14:58:18Z")
> [@Greg\_O](#): > > anything that Xojo publishes, whether it’s by one of the employees or by a guest contributor becomes part of the canon of best practices for Xojo. The problem here is that the use of DoEvents is definitely not a best practice and one could argue that it’s a worst practice for all intents and purposes. I would think Xojo should remove the post because Xojo’s examples need to be _best practices_. ---
**Author:** ![Thom\_McGrath](https://forum.xojo.com/user_avatar/forum.xojo.com/thom_mcgrath/32/192_2.png) [@Thom\_McGrath](https://forum.xojo.com/u/Thom_McGrath)\ **Post date:** [November 29, 2025, 3:00pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/16 "2025-11-29T15:00:33Z")
> [@ChristopheDV](#): > > It would be great if you provided us a project that show cases it can crash, do odd things, behave oddly, … in a **use case scenario**. Sure. Take a look at my most recent article about preemptive threading: [The ZAZ: Navigating the Perils of Preemptive Threads and Locking](https://thezaz.com/blog/navigating_the_perils_of_preem) In the “Only Nearly Foolproof?” section near the end there are two examples that will be a problem. Neither use DoEvents directly, but cause the exact same problem. The first is one that any experienced dev should catch on to being problematic. But the second is really sneaky. Timers and sockets are the best ways to get into trouble with DoEvents. You can do something simple like setup a timer, then a button with a loop that runs DoEvents, and the timer’s action even will fire inside the button’s pressed handler. Whether or not this is a problem really depends on what the code is doing, but it leads to really hard to find issues. I suspect since you’re not threading, you probably haven’t noticed anything wrong, but that doesn’t mean it’s safe. You just haven’t been burned by it. But I’m also concerned that you think threading is impossible in your app. That’s a bigger warning sign that the code is not healthy. ---
**Author:** ![Thom\_McGrath](https://forum.xojo.com/user_avatar/forum.xojo.com/thom_mcgrath/32/192_2.png) [@Thom\_McGrath](https://forum.xojo.com/u/Thom_McGrath)\ **Post date:** [November 29, 2025, 3:02pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/17 "2025-11-29T15:02:01Z")
> [@Tim\_Parnell](#): > > I would think Xojo should remove the post because Xojo’s examples need to be _best practices_. I agree. I wanted to comment on it moments after it was published, but Xojo doesn’t allow comments on their blog posts. I almost texted Geoff, but decided it wasn’t my problem. ---
**Author:** ![ChristopheDV](https://forum.xojo.com/letter_avatar_proxy/v4/letter/c/59ef9b/32.png) [@ChristopheDV](https://forum.xojo.com/u/ChristopheDV)\ **Post date:** [November 29, 2025, 3:21pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/18 "2025-11-29T15:21:53Z")
> [@Thom\_McGrath](#): > > Timers and sockets are the best ways to get into trouble with DoEvents. You can do something simple like setup a timer, then a button with a loop that runs DoEvents, and the timer’s action even will fire inside the button’s pressed handler. OK, I have tried this but that is not the case here and I cannot get to trigger the Timers action event in the button Pressed event. I ended up adding more Timers and buttons with doevents() loops. Still, it just works fine. Anyhow, I am aware what doevents() exactly does and I understand it very well too. And it may go wrong in some use cases. 99 out 100 it is ok and will do no harm. As said, it has some use cases and should not be removed. ---
**Author:** ![Thom\_McGrath](https://forum.xojo.com/user_avatar/forum.xojo.com/thom_mcgrath/32/192_2.png) [@Thom\_McGrath](https://forum.xojo.com/u/Thom_McGrath)\ **Post date:** [November 29, 2025, 3:44pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/19 "2025-11-29T15:44:44Z")
> [@ChristopheDV](#): > > As said, it has some use cases and should not be removed. It does not have any legit use cases in a desktop app. You’re right, and Greg said it too: it works ok until it doesn’t. Here’s what I mean about the timer firing inside the pressed event. Look at the stack. That’s not normal. But as I said, whether or not it actually causes a problem depends entirely on what else the code is doing. Regardless, using DoEvents has messed up the natural order of event flow. Button1.Pressed starts, Timer1.Action starts, Timer1.Action ends, and Button1.Pressed ends. That kind of nonsense should never happen. ![SCR-20251129-jsip](https://forum.xojo.com/uploads/default/original/3X/9/0/90832a43e0f4b2be5a6d389fcdb9e82f35eb1c2b.png) [DoEvents.xojo\_binary\_project.zip](https://forum.xojo.com/uploads/short-url/oiJebW0lDYtX0OepLe0kt2WzKjT.zip) (5.0 KB) ---
**Author:** ![ChristopheDV](https://forum.xojo.com/letter_avatar_proxy/v4/letter/c/59ef9b/32.png) [@ChristopheDV](https://forum.xojo.com/u/ChristopheDV)\ **Post date:** [November 29, 2025, 3:52pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/20 "2025-11-29T15:52:07Z")
> [@Thom\_McGrath](#): > > That kind of nonsense should never happen I see. Still it does no harm. 🙂 But I get it. ---
**Author:** ![Jeremie\_L](https://forum.xojo.com/user_avatar/forum.xojo.com/jeremie_l/32/150_2.png) [@Jeremie\_L](https://forum.xojo.com/u/Jeremie_L)\ **Post date:** [November 29, 2025, 4:01pm UTC](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096/21 "2025-11-29T16:01:26Z")
@Greg_O or @Thom_McGrath would you have any input on my initial question? > [@Jeremie\_L](#): > > When using App.DoEvents in a **Console** app, is it better to use the default 10ms delay or increase that value? > > […] > > My use case is a Console app running the main routines in Threads with heavy use of URLConnection async calls. [Next page](https://forum.xojo.com/t/re-optimizing-xojo-code-part-1-getting-started/87096.md?page=2)