Coder Perfect

Use of Application.DoEvents()


Is it possible to utilize Application.DoEvents() in C#?

Is this a function that, like VB6’s DoEvents, allows the GUI to catch up with the rest of the app?

Asked by Craig Johnston

Solution #1

The enduring mystique of DoEvents is Hmya (). There has been a huge pushback against it, but no one ever truly explains why it is “wrong.” “Don’t change a struct,” for example, is sound advice. Why, if modifying a struct is so terrible, does the runtime and language support it? Same reason: if you don’t do it correctly, you’ll shoot yourself in the foot. Easily. And doing it correctly necessitates understanding exactly what it does, which is not easy in the case of DoEvents().

Right off the bat: almost any Windows Forms program actually contains a call to DoEvents(). It is cleverly disguised, however with a different name: ShowDialog(). It is DoEvents() that allows a dialog to be modal without it freezing the rest of the windows in the application.

When writing their own modal loop, most programmers wish to use DoEvents to prevent their user interface from freezing. It absolutely accomplishes this; it sends Windows messages and fulfills any paint requirements. The problem however is that it isn’t selective. It not only dispatches paint messages, it delivers everything else as well.

There’s also a series of notifications that are problematic. They originate approximately 3 feet in front of the monitor. While the loop that runs DoEvents() is running, the user could, for example, close the main window. That works, and the user interface is no longer present. Your code, on the other hand, did not stop; it is continuously running the loop. That’s not good. It’s terrible.

There’s more to come: The user might select the same menu item or press the same button to initiate the same loop. You now have two nested loops running DoEvents(), with the previous loop suspended and the new loop started from the beginning. That might work, but the chances are minimal. Particularly when the nested loop terminates and the suspended one begins, attempting to perform a task that has already been accomplished. If that doesn’t go off without a hitch, the data has most likely been scrambled to heck.

Return to the ShowDialog page (). It calls DoEvents(), but there’s a catch: it also does something else. Except for the dialog, it turns off all of the application’s windows. The user can no longer tamper with the logic now that the 3-foot problem has been fixed. Close-the-window and restart-the-job failure mechanisms are both resolved. To put it another way, the user has no method of forcing your application to execute code in a different order. It will behave in the same way it did when you tested your code. It makes dialogs exceedingly inconvenient; who doesn’t despise having a dialog open and being unable to copy and paste from another window? But that is the cost.

That’s all it takes to safely use DoEvents in your code. To avoid difficulties, set the Enabled property of all your forms to false. Of course, no coder enjoys working in this environment. Also, it doesn’t. That is why DoEvents should not be used (). Threads should be used. Despite the fact that they provide you with a vast arsenal of colorful and perplexing ways to fire your foot. However, you can only fire your own foot; it won’t let the user shoot hers (usually).

The new await and async keywords in the forthcoming versions of C# and VB.NET will provide a different gun. Inspired in part by the headaches caused by DoEvents and threads, but mostly by WinRT’s API design, which compels you to keep your UI updated while an asynchronous action is running. It’s similar to reading from a file.

Answered by Hans Passant

Solution #2

It’s possible, but it’s a ruse.

See Is DoEvents Evil? for more information.

The following is taken directly from the MSDN page that thedev referred to:

As a result, Microsoft advises against using it.

I also consider it a hack because its behaviour is unpredictably unpredictable and prone to side effects (this comes from experience trying to use DoEvents instead of spinning up a new thread or using background worker).

There’s no machismo here; if it worked as a reliable solution, I’d jump on it. Trying to use DoEvents in.NET, on the other hand, has been excruciating.

Answered by RQDQ

Solution #3

Yes, the Application class in the System has a static DoEvents function. System.Windows.Forms.Application is a namespace in the Windows.Forms namespace. When conducting a long-running activity in the UI thread, DoEvents() can be used to process the messages waiting in the queue. This improves the UI’s responsiveness and prevents it from becoming “frozen up” when a long job is executing. However, this is virtually never the best course of action. DoEvents “causes the current thread to be paused while all waiting window messages are processed,” according to Microsoft. If an event is triggered, there is a risk of unpredictably and intermittently occurring bugs that are difficult to track down. If you have a large task, it is considerably better to complete it all at once.

Here’s an example of how to utilize DoEvents; keep in mind that Microsoft warns against using it.

Answered by Bill W

Solution #4

Using DoEvents in.NET should be approached with caution, in my opinion. When I used DoEvents in a TabControl containing DataGridViews, I got some unexpected results. If all you’re dealing with is a small form with a progress indicator, on the other hand, it might be fine.

The main line is that if you’re going to use DoEvents, you should properly test it before releasing your project.

Answered by Craig Johnston

Solution #5


If you need to utilize Application.DoEvents, it’s usually a sign of a poorly designed application. Perhaps you’d want to work on something else in a separate thread?

Answered by Frederik Gheysels

Post is based on