a companion discussion area for blog.codinghorror.com

Is DoEvents Evil?


I don’t know why you would use this quote from Dan T that is completely wrong:

DoEvents messes up the normal flow of your application. If I recall correctly, DoEvents is asynchronous which means it terminates before the application has actually processed any outstanding events

No, DoEvents is synchronous; it returns only once all outstanding events have been processed. Yes, the user might click the same button again (you should have disabled the button, duh), or perform other actions that could cause the same code to be re-entered “unexpectedly”, but multithreading has the same problem, only worse: with multithreading a button can not only be clicked a second time, but if you’re not very careful, the same data could be manipulated by different threads at the same time!

(I know this post is old but it’s still a top Google result for “.NET DoEvents” so I feel compelled to correct this error.)

DoEvents is usually not the solution that provides the best user experience, but even in 2014, it’s often still the easiest.


I really liked Lucian Wischik’s NDC 2013 discussion on async feature in C# 5.0 as it relates to Progress generic class. I feel it solves the problem of long-running task and updating UI in an elegant way:


I agree that DoEvents has a place. I’d welcome any civilized arguments against it, but Dan Tohatan’s statements turned me off completely. As he labels anyone using DoEvents as “mediocre”, I label anyone spewing such comments as an elitist jerk.


Eh, how do I use a progress bar when the Form doesn’t repaint? It’s kind of silly to progress the progress bar, if the user cannot see the progress bar progressing, since the form is frozen. And yes, I really would like to include the word “progress” even more in the previous sentence. :wink:


[quote=“codinghorror, post:1, topic:1233, full:true”]
Never underestimate the power of perceived performance[/quote]

So much this. I inherited an application which has a few functions that take some time to load. Users complimented me that it is so much faster since I layed my hands on it. In reality all I did was give the user some feedback that the application is still working. I changed nothing at all how the data is being processed, so it simply cannot run any faster than before, but the users perceive an increase in performance because now they can actually see that the program is doing some work.


I recently did a bit of VBA programming with Excel, DoEvents makes a huge difference in that environment for perceived performance. I still do the locking but having it not lock the screen while it runs a very large macro makes it feel more polished.


What a ridiculous discussion. We program to make money. We do whatever we can to make an application look and feel the best it can be, and stable, with the least development time. How quickly we do it directly affects whether we earn lawyer’s or MacDonald’s counter style wages. For goodness sake - what kind of cods wallop is this discussion? Enable buttons when you need them and disable when don’t want them to be pressed. Use progress bars, popup wait messages, whatever you can think of to keep the user occupied while you crunch whatever it is you need to crunch, Properly index your databases. Normalize only a little. And multi thread only under duress. Please.