1

I have a winforms application which makes calls to Application.DoEvents(). Now the app freezes around the time this method is called (no surprise).

However, this only happens on some machines. Is it fair to say that this would be due to machine itself or is it still down to the code/application.doevents()? In which case, it should be refactored to use backgroundworker.

Would this be a machine/environment issue or an oppurtunity to use backgroundworker?

Niels Keurentjes
  • 41,402
  • 9
  • 98
  • 136
GurdeepS
  • 65,107
  • 109
  • 251
  • 387

1 Answers1

6

Use a background worker if you can. DoEvents is a 'hack' to allow your application to remain responsive, and process WM_PAINT messages mostly, when it's doing something it should actually never be doing: blocking execution for more than a reasonable time during message processing in the main GUI loop. If DoEvents causes a hang instead of fixing it, you have too many messages spending way too much system power. Fork them out to background workers to fix all of it at once - it's just a matter of time before "some machines" becomes "most machines" otherwise.

Niels Keurentjes
  • 41,402
  • 9
  • 98
  • 136
  • Thanks. How can I explain the fact this issue does not happen on all machines? – GurdeepS May 10 '13 at 15:04
  • Numerous possibilities: race conditions, different OS's, different amount of background/foreground jobs, CPU speeds, slower I/O subsystems, you name it. The problem with 'system overload' is that it's nearly always threshold-based - as long as it can process everything under constant load, everything remains responsive, but once the threshold is reached where it can **not** it will start to get more and more delayed because of the continuing influx, up to the point of stalling. The line between 'not' and 'fully' overloaded is often a thin one. – Niels Keurentjes May 10 '13 at 15:16