Mattias is right. Application.DoEvents() does not block the process, it
pushes the messages on the message loop through, so that it appears to the
user that the gui is still responsive. But the other processes on the
machine will still be CPU starved, if this is what you are trying to avoid.
You may want to investigate using another thread instead of using
Application.DoEvents(). Also, be aware of what App.DoEvents really does. It
stops your process wherever it is and handles all windows messages. So
imagine the scenario where the user clicks a button, some heavy work hits,
and the gui goes non responsive. The user starts clicking around to see if
it's dead. Then you call App.DoEvents, and your intensive process is paused
while all of their clicks are processed. Now imagine that one of those
clicks they made was on the button that starts the heavy work. Now you're
running two copies of the heavy code, one execution occurring inside the
other.
Another scenario - imagine a database bound form with a save and close
button. The user clicks save, then while that's going, clicks cancel, and
you call App.DoEvents, the cancel event goes through and you close the form.
Then the save finishes and you go back to update the state of the form...
App.DoEvents should be used with caution.
Niall
"george" <ge************@kingland.com> wrote in message
news:E6**********************************@microsof t.com...
I am writing a process that is a tight loop that consumes alot of cpu.
Back in my VB days I could use "DoEvents" to periodically yield control to
the OS incase there were any pending events. This would keep the app from
being able to effectively take over the system. What is the equivilant in
C#?
