a companion discussion area for blog.codinghorror.com

Is DoEvents Evil?


It's an old VB developer trick, but it also works quite well in .NET: to present responsive WinForms interfaces, do most of your heavy lifting in the first Paint event, rather than in the Load event. I've seen many naive WinForm developers perform database queries and other heavyweight operations in the Form Load event, which absolutely kills perceived performance-- the form doesn't even display until all the work is done! It's much better to render part of the form first so the user gets immediate visual feedback, beyond an hourglass cursor, that stuff is happening.

This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/12/is-doevents-evil.html


DoEvents is really bad. You can use a progress bar or some other method to let the user know what is going on. DoEvents lets other events execute out of order and can really ruin your day :slight_smile:


As with so many things, it depends. You definitely need to be careful. There is a followup post on DoEvents here:



I’s definitly a cheap shot however, sometimes a cheap shot is all it takes…


i found this article by searching for “DoEvents is evil”

i’ve inherited a gigantic broken application that makes liberal, sensless use of DoEvents.

The horror! the horror!


DoEvents is evil!?
Who said DoEvents allows a user to start multiple threads?


If you don’t want this, all you need is to declare a boolean variable named ‘IsProcessing’ or something… and, well, you get the rest.


I still don’t get the idea
why people said that DoEvents is evil!?

I never used it before, while testing i see that DoEvents is almost same as refresh()

Am I correct?


To the Guy who said 'the user clicks the button again’
You need to lock out the user from doing that.

It is not that difficult
Here is a sample of how I do it:


Doh! I mean:

btnCancel.Visible = False


This is such a basic (ewwwe a pun)thing that it saddens me that so many ‘programmers’ don’t get it… If you understand your own program flow, if you KNOW HOW YOUR CODE WORKS, then DoEvents is not only fine, but it’s brilliant and you will have no problems.

If you are one of the many-and-growing who don’t really even understand your own program’s flow (cough 90% open source cough), you should not only not use DoEvents, but you shouldn’t use delegation or mutithreading either because you aren’t a programmer , you are a voodoo practitioner…

I know you read in that it was ‘bad’ on a blog or a magazine, or a great book, but they should have to caviat that with ‘…if you have no idea what your really doing…’



It may be because I am relatively new to all this, but I struggle to see what all the fuss is about.

As I see it, .NET 2.0 programmers have three choices:

(1) Use Application.DoEvents()
(2) Use a threading model of your choice
(3) Use the BackgroundWorker class

Surely they all have the same issue: Your application needs to be written carefully, and, in particular, you need to disable certain user controls before you start a long-running process, so that the application doesn’t get its knickers in a twist.

All three methods require care - and I can’t see that one is massively better than any other.

I agree with Daniel - it’s just a matter of knowing how your application works. Any strong preference for one method over the other seems to me to be rather evangelical rather than practical.

I will be using the BackgroundWorker class in my next application. I will be using it purely because I want to gain experience with the various practices in .NET. I have a feeling that using Application.DoEvents() would be much simpler, and make no difference whatsover to the efficiency, maintainability and user-experience of the application.

Perhaps the advantages or disadvantages of each approach becomes more apparent in long, sprawling programs?


There is only one case where I really had to use Application.DoEvent().

Scenario: A thread is processing incoming data and post it (via BeginInvoke) to the UI thread for display. At some point, you want to terminate properly both data gathering and data display processes.

The thing is, depending on the system load, you might have no idea how many BeginInvoke calls need to be processed. Assuming that your data gathering thread is dead, how could you be sure that no more BeginInvoke calls remains to be processed? Simply call Application.DoEvent(), this will get rid of every BeginInvoke calls still in the queue. There is no other ways.

Don’t tell me to switch from BeginInvoke to Invoke, in some case you simply can’t. Our only hope in that case is that Microsoft NEVER remove Application.DoEvent(). Quickly think of it, I’m pretty sure that the only scenario where this is really needed.

In brief, when you want to be sure that no more BeginInvoke calls launched from a dead thread remains to be done, call Application.DoEvent().


There is always people who will feel superior to put in practice “tough” or “macho” programming techniques, wasting time “and clients money” using something that later will bring bigger headaches (threading) for something that can be solved the easy way.

Dan Tohatan is wrong, I agree with the “refresh” comment, the way to make the Interface
display properly while precessing something long in the loop is to call the refresh method in the form (if you add a progress bar is even better). so that if you are switching screens to other apps and coming back to check the progress you will still see something and not just a white square.
The DoEvents is used ONLY FOR the PURPOSE to allow the user to actually click on some control in the form while processing (best example: a cancel button), so DOEVENTS is really very useful for what it was intendend, now if people use it the wrong way that’s another story… I can see many related posts “DoEvents Considered Harmful” :slight_smile:


I started out as a Java programmer personally - threading there is - in my humble opinion - much simpler where your able to simply inherit from the thread object then use a nice simple set of flags in the new object and some nice accessor methods to control the thread flow.

However that said I really don’t see what the big fuss about using thread in .NET is either. Generally good OO program doesn’t INCLUDE much - if any shared memory and simply adhering to good coding procedures keeps your code clean enough for threading to be safe.

That said I concede after reading this that App.DoEvents certainly has its place in the programmers arsenal. Never throw away a perfectly good tool.


Good work, Jeff, thx. I found another good resource at http://blogs.msdn.com/jfoscoding/archive/2005/08/06/448560.aspx - it provides some solutions for the known problems of DoEvents().


Sorry, the link’s gone… here again: http: // blogs.msdn.com / jfoscoding / archive / 2005 / 08 / 06 / 448560.aspx


@Daniel (on October 16, 2007 09:26 AM)

Do you think that open source programmers don’t know the program’s flow? And what do you think about the fact that Linux (caution, an open source operating system) don’t need to accommodate an obscure DoEvents() method? Is a possible answer the fact that in Linux the XServers are clearly uncoupled from XClients through the XProtocol?

In other words: Is it possible, that MS Windows is made by many-and-growing programmers (as you said) or why is there a need for a such dirty method like ‘DoEvents()’ (- DoEvents() WILL break your program’s flow)?

I have no preference… please be careful when drawing comparisons.


Sorry but the only real reason to use doevents is laziness.
Nothing other.

For refreshing a button when doing heavy load stuff – I just laught when i read that.


DoEvents is very useful! It’s certainly not evil… unless you’re the soft of programmer who gets confused easily… in which case you should probably go play with some crayons or revert to VB6


Thanks for the information. I decided to use DoEvents to allow users to cancel out of a long-running process. With your support, I now feel reassured.

And yet, strangely, emasculated, too.