By user541686

2012-07-05 20:45:29 8 Comments

A simple search for DoEvents brings up lots of results that lead, basically, to:

DoEvents is evil. Don't use it. Use threading instead.

The reasons generally cited are:

  • Re-entrancy issues
  • Poor performance
  • Usability issues (e.g. drag/drop over a disabled window)

But some notable Win32 functions such as TrackPopupMenu and DoDragDrop perform their own message processing to keep the UI responsive, just like DoEvents does.
And yet, none of these seem to come across these issues (performance, re-entrancy, etc.).

How do they do it? How do they avoid the problems cited with DoEvents? (Or do they?)


@Joel Coehoorn 2012-07-05 21:07:02

DoEvents() is dangerous. But I bet you do lots of dangerous things every day. Just yesterday I set off a few explosive devices (future readers: note the original post date relative to a certain American holiday). With care, we can sometimes account for the dangers. Of course, that means knowing and understanding what the dangers are:

  • Re-entry issues. There are actually two dangers here:

    1. Part of the problem here has to do with the call stack. If you call .DoEvents() in a loop that itself handles messages that use DoEvents(), and so on, you're getting a pretty deep call stack. It's easy to over-use DoEvents() and accidentally fill up your call stack, resulting in a StackOverflow exception. If you're only using .DoEvents() in one or two places, you're probably okay. If it's the first tool you reach for whenever you have a long-running process, you can easily find yourself in trouble here. Even one use in the wrong place can make it possible for a user to force a stackoverflow exception (sometimes just by holding down the enter key), and that can be a security issue.
    2. It is sometimes possible to find your same method on the call stack twice. If you didn't build the method with this in mind (hint: you probably didn't) then bad things can happen. If everything passed in to the method is a value type, and there is no dependance on things outside of the method, you might be fine. But otherwise, you need to think carefully about what happens if your entire method were to run again before control is returned to you at the point where .DoEvents() is called. What parameters or resources outside of your method might be modified that you did not expect? Does your method change any objects, where both instances on the stack might be acting on the same object?
  • Performance Issues. DoEvents() can give the illusion of multi-threading, but it's not real mutlithreading. This has at least three real dangers:

    1. When you call DoEvents(), you are giving control on your existing thread back to the message pump. The message pump might in turn give control to something else, and that something else might take a while. The result is that your original operation could take much longer to finish than if it were in a thread by itself that never yields control, definitely longer than it needs.
    2. Duplication of work. Since it's possible to find yourself running the same method twice, and we already know this method is expensive/long-running (or you wouldn't need DoEvents() in the first place), even if you accounted for all the external dependencies mentioned above so there are no adverse side effects, you may still end up duplicating a lot of work.
    3. The other issue is the extreme version of the first: a potential to deadlock. If something else in your program depends on your process finishing, and will block until it does, and that thing is called by the message pump from DoEvents(), your app will get stuck and become unresponsive. This may sound far-fetched, but in practice it's surprisingly easy to do accidentally, and the crashes are very hard to find and debug later. This is at the root of some of the hung app situations you may have experienced on your own computer.
  • Usability Issues. These are side-effects that result from not properly accounting for the other dangers. There's nothing new here, as long as you looked in other places appropriately.

If you can be sure you accounted for all these things, then go ahead. But really, if DoEvents() is the first place you look to solve UI responsiveness/updating issues, you're probably not accounting for all of those issues correctly. If it's not the first place you look, there are enough other options that I would question how you made it to considering DoEvents() at all. Today, DoEvents() exists mainly for compatibility with older code that came into being before other credible options where available, and as a crutch for newer programmers who haven't yet gained enough experience for exposure to the other options.

The reality is that most of the time, at least in the .Net world, a BackgroundWorker component is nearly as easy, at least once you've done it once or twice, and it will do the job in a safe way. More recently, the async/await pattern or the use of a Task can be much more effective and safe, without needing to delve into full-blown multi-threaded code on your own.

@Ben Voigt 2012-07-05 22:57:28

How about the simple fact that your main message loop is not used while dispatching messages inside the modal loop, and therefore all the special things you might do (MsgWaitForMultipleObjects anyone, or idle processing) will not be done until the modal loop finishes?

@Deanna 2012-07-09 10:16:19

I've added a note about the reentrancy issue in my answer to this question.

@Yuhong Bao 2013-05-04 02:02:27

Of course, threading can be dangerous too if you aren't careful.

@Joe 2012-07-05 21:04:33

I may be wrong, but it seems to me that DoDragDrop and TrackPopupMenu are rather special cases, in that they take over the UI, so don't have the reentrancy problem (which I think is the main reason people describe DoEvents as "Evil").

Personally I don't think it's helpful to dismiss a feature as "Evil" - rather explain the pitfalls so that people can decide for themselves. In the case of DoEvents there are rare cases where it's still reasonable to use it, for example while a modal progress dialog is displayed, where the user can't interact with the rest of the UI so there is no re-entrancy issue.

Of course, if by "Evil" you mean "something you shouldn't use without fully understanding the pitfalls", then I agree that DoEvents is evil.

@Gabe 2012-07-05 20:54:10

Back in 16-bit Windows days, when every task shared a single thread, the only way to keep a program responsive within a tight loop was DoEvents. It is this non-modal usage that is discouraged in favor of threads. Here's a typical example:

' Process image
For y = 1 To height
    For x = 1 to width
        ProcessPixel x, y
    End For
    DoEvents ' <-- DON'T DO THIS -- just put the whole loop in another thread
End For

For modal things (like tracking a popup), it is likely to still be OK.

Related Questions

Sponsored Content

35 Answered Questions

[SOLVED] How do I run Redis on Windows?

  • 2011-06-25 09:23:33
  • DaveHeller
  • 556241 View
  • 602 Score
  • 35 Answer
  • Tags:   windows redis

30 Answered Questions

[SOLVED] How can you find out which process is listening on a port on Windows?

18 Answered Questions

[SOLVED] How do I run two commands in one line in Windows CMD?

14 Answered Questions

[SOLVED] How to run a PowerShell script

16 Answered Questions

[SOLVED] How do I install a Python package with a .whl file?

47 Answered Questions

[SOLVED] How do I update the GUI from another thread?

37 Answered Questions

[SOLVED] How to install pip on Windows?

39 Answered Questions

[SOLVED] How can I develop for iPhone using a Windows development machine?

  • 2008-08-22 13:35:01
  • ryan
  • 1113038 View
  • 1191 Score
  • 39 Answer
  • Tags:   ios iphone windows

1 Answered Questions

Is DoEvents() also evil in FormClosing?

Sponsored Content