Application.DoEvents()

[Jeremy S.]

Application.DoEvents();

Why would I ever want to do that? When is it (1) required, or (2) a "good
idea" or (3) a "bad idea"

Thanks.

 

[Nicholas Paldino [.NET/C# MVP]]

Jeremy,

While there are some legitimate uses for calling DoEvents, more often
than not, it is used to pump messages in the UI thread when performing a
long-running task in the UI thread. Generally, this is a bad idea, as you
should process that task in another thread, and then marshal calls to update
the UI back to the UI thread through a call to the Invoke method.

To be honest, it is mainly for the VB crowd.

Is it ever required? No.

Is it a good idea? No.

Is it a bad idea? Almost always yes. For the reasons why, see a
previous post by me on this topic:

http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/bcb7064ad2629734

 

[Jeremy S.]

Thanks Nicholas. Very helpful.

Jeremy,

While there are some legitimate uses for calling DoEvents, more often
than not, it is used to pump messages in the UI thread when performing a
long-running task in the UI thread. Generally, this is a bad idea, as you
should process that task in another thread, and then marshal calls to
update the UI back to the UI thread through a call to the Invoke method.

To be honest, it is mainly for the VB crowd.

Is it ever required? No.

Is it a good idea? No.

Is it a bad idea? Almost always yes. For the reasons why, see a
previous post by me on this topic:

http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/bcb7064ad2629734


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Application.DoEvents();

Why would I ever want to do that? When is it (1) required, or (2) a "good
idea" or (3) a "bad idea"

Thanks.

 

[zacks]

Thanks Nicholas. Very helpful.

message

I disagree. I have found that applications that interact with the user
interface, like a progress meter when performing a long running task,
then updates to the user interface will not happen unless the system
DoEvents in the application's main processing loop that is updating
the progress meter.

Now, this is the only time I have ever seen the need to use the
DoEvents call. But it is the only way I have found to get UI updates
to be seen while the app is busy.

 

[Jon Skeet [C# MVP]]

I disagree. I have found that applications that interact with the user
interface, like a progress meter when performing a long running task,
then updates to the user interface will not happen unless the system
DoEvents in the application's main processing loop that is updating
the progress meter.

Now, this is the only time I have ever seen the need to use the
DoEvents call. But it is the only way I have found to get UI updates
to be seen while the app is busy.

DoEvents is a hacky answer to that problem. It introduces the
possibility of re-entrancy, which is horrible.

The *correct* answer to the problem is to put the long-running task
into a separate thread, so that the UI thread can stay responsive.

See http://pobox.com/~skeet/csharp/threads/winforms.shtml

 

[Chris Shepherd]

I disagree. I have found that applications that interact with the user
interface, like a progress meter when performing a long running task,
then updates to the user interface will not happen unless the system
DoEvents in the application's main processing loop that is updating
the progress meter.

Now, this is the only time I have ever seen the need to use the
DoEvents call. But it is the only way I have found to get UI updates
to be seen while the app is busy.

Long running tasks should be running in another thread, which negates
the need to use DoEvents, and makes a lot of things actually work
properly in terms of your UI not blocking. The BackgroundWorker class
has mechanisms to support progress updating, so it's pretty much
designed to do exactly this.

Chris.

 

[Doug Semler]

I disagree. I have found that applications that interact with the user
interface, like a progress meter when performing a long running task,
then updates to the user interface will not happen unless the system
DoEvents in the application's main processing loop that is updating
the progress meter.

Now, this is the only time I have ever seen the need to use the
DoEvents call. But it is the only way I have found to get UI updates
to be seen while the app is busy.

I've only seen this behavior in two situations:
1) The "long running task" is running on the same thread as the GUI
(i.e. it's actually a function called from something like a button
event handler) and not in a background thread
2) CPU starvation. I usually can fix this by lowering the priority
of my background task.

 

[zacks]

DoEvents is a hacky answer to that problem. It introduces the
possibility of re-entrancy, which is horrible.

The *correct* answer to the problem is to put the long-running task
into a separate thread, so that the UI thread can stay responsive.

Seehttp://pobox.com/~skeet/csharp/threads/winforms.shtml

I appreciate all of the replies to my comment. Looks like I need to
figure out and start using Threads.

 

[Michael S]

I appreciate all of the replies to my comment. Looks like I need to
figure out and start using Threads.

Application.DoEvents is taken straight from Delphis
Application.ProcessMessages,
and the same re-entry problem has been known for like 15 years now.

In the forum there was once a day a dude who wondered why his events got
shot at trice,
or why it went into an infinite loop. When you see events that goes:
{
(if alreadyInside)
return;
alreadyInside = true;
//.. real code here
alreadyInside = false;
}

you can be sure some poor programmer has re-entry problems.

With .NET 2.0 and the BackgroundWorker component, I think DoEvents should be
avoided at all costs.

- Michael Starberg