How can a Windows Forms application that relies heavily on Application.DoEvents() be made less unstable without having to re-design it?

StackOverflow https://stackoverflow.com/questions/15704037

Question

The application that I'm now in charge of maintaining relies heavily on the Application.DoEvents() method, and while I do not have solid proof that all the sudden and inexplicable application crashes are caused by the use of this method, so far most of the problems that I have identified seem to be in some way related to the way the flow of the execution of the code centers around this method.

The pattern I've seen throughout the code is more or less as follows:

  1. User-triggered event is fired

  2. Event handler procedure runs

Then either:

  1. A new thread is spawned

  2. Rather than blocking the UI thread and the UI until the spawned thread is no longer running, or letting control leave the event handler procedure, the code loops, calling Application.DoEvents() each pass, until it receives a signal indicating that the spawned thread is no longer running. (There might even be some cases when Application.DoEvents() is concurrently called by the spawned thread as it waits for other events to complete.)

  3. The pattern seen in #2 is repeated a number of times before control is allowed to leave the event handler procedure.

or:

  1. A form is created and shown via Show() or ShowDialog() method.

  2. Rather than blocking the UI thread and the rest of the UI until the user interacts with the Form, or letting control leave the event handler procedure, the code loops, calling Application.DoEvents() each pass, until it receives a signal indicating that the user has interacted with the Form.

  3. The next Form is displayed to the user, and the same drill is repeated until many Forms later control is finally allowed to leave the event handler procedure.

I know that it's hard to diagnose problems when you don't have the code right in front of you, but assuming that the calls to Application.DoEvents() are in some way related to this application's erratic behavior, what would be the simplest way to fix this application without having to re-design it from the ground up?

Is it just a matter of having the event handler procedure spawn a new thread, allow control to leave the event handler procedure right away, and then instead of repeatedly calling Application.DoEvents(), block the spawned thread, using a WaitHandle or some other signaling mechanism, until the spawned thread receives notification that another thread has done its job or the user has interacted with a form?

Was it helpful?

Solution

Besides of good tips with removing DoEvents from threads, have you tried to play with BackgroundWorker class? It's better suited for simple threads operations and communication with forms. http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx http://www.dotnetperls.com/backgroundworker

OTHER TIPS

You have multiple, big problems with your inherited design. Without using nuclear weapons, as suggested by Hans, (and not a bad idea, actually), start by absolutely getting rid of any Application.DoEvents() calls from non-GUI threads.

Then start on the other piles of manure.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top