“Applicaton.DoEvents() processes all Windows messages currently in the message queue” is how the msdn defines it. It has been a developer’s tool to organize the response of forms in .net. But it has got its own limitations attached with it.Its own good, bad and ugly attributes. So, let’s see the different faces of it.
The Good: In a windows application whenever a win form handles an event, it processes all the code associated with it. All other events wait in a queue. As a result what happens is your form becomes unresponsive. This might not be a problem if the time is negligible. But suppose there are loops running, performing heavy database queries. The form would not respond for a long time & the user does not get a visual feedback of the stuff happening behind. The use of Applicaton.DoEvents() inside the loops makes the form responsive or repaints the form, giving user a better experience with the application. What it actually does is yields the UI thread which has been waiting. This is really a very good option for giving a crisp response by the form while having a busy event.
The Bad: The thing which developers usually forget is that Applicaton.DoEvents() process “all the Messages in the queue”, not just the paint message or UI thread. I’ll explain this with a similar problem which I faced on a project. The application contained a form having some heavy database process going behind in long loops. Application.DoEvents() was placed in the loop to make the form responsive. The application also had a timer which had codes that interfered with the database process going behind the form. So, it was turned off during the process. Now, when Application.DoEvents() was fired all the messages in the message queue were processed, in which some of them invoked the timer giving an application crash. This is a small example. In complex situations Application.DoEvents() messes up the normal flow of the program execution, leaving the developer clueless about the processes going on.
The Ugly: The ugly truth is that the alternative of Application.DoEvents() would be a complex hard core threading or else you will end up with a bad UI.
DoEevents is not a perfect solution, but it can be used instead of complex threading for simple problem. I mean if your situation is not a complex one, then DoEvents can be one of the best options for a better responsive UI. Otherwise, you need to be ultra careful while dealing with DoEvents.