Is DoEvents a no-no?

[Emby]

Back in VB6, there was "healthy debate" over whether DoEvents should be
used, or it was just too evil ;-)

One can certainly argue that there is a need for a mechanism to have one
routine yield the processor to another. For example, when a file open/save
dialog is closed, the code opening or saving the selected file may want to
allow the application window that was partially occluded by the dialog an
opportunity to repaint itself.

Now in .NET, we have System.Windows.Forms.Application.DoEvents, and this
does indeed seem to provide the required respite, yielding the CPU to other
code in the App.

But is there a better, more general (i.e., not part of the Forms namespace)
way of achieving this? One might consider Thread.Sleep, but it looks like
this blocks the thread all together - a problem if the code you want to
allow to run is to be executed on the same thread.

I'd appreciate any opinions on this topic ...

Thanks.

 

[Jon Skeet [C# MVP]]

Back in VB6, there was "healthy debate" over whether DoEvents should be
used, or it was just too evil ;-)

One can certainly argue that there is a need for a mechanism to have one
routine yield the processor to another. For example, when a file open/save
dialog is closed, the code opening or saving the selected file may want to
allow the application window that was partially occluded by the dialog an
opportunity to repaint itself.

Now in .NET, we have System.Windows.Forms.Application.DoEvents, and this
does indeed seem to provide the required respite, yielding the CPU to other
code in the App.

But is there a better, more general (i.e., not part of the Forms namespace)
way of achieving this? One might consider Thread.Sleep, but it looks like
this blocks the thread all together - a problem if the code you want to
allow to run is to be executed on the same thread.

I'd appreciate any opinions on this topic ...

The better way is to use a background thread - don't block the UI
thread in the first place.