threading question

[Peter Duniho]

Sorry to interrupt, but you assert here that calling DoEvents is a bad
thing to do. Why is that?

I believe that this has been covered in a variety of forums already,
including this one.

But the short answer is that in a correctly-structured application, it's
not necessary and, among other potential problems, it creates the
potential for re-entrant behavior in code that was written by someone
unlikely to be well-equipped to deal with ensuring that this potential is
not realized, or otherwise correctly handling the potential. That is,
someone who knows enough about the risks and how to manage them also knows
enough about how to fix the code so that calling DoEvents() isn't required
in the first place.

I have seen others argue in favor of using it, but the argument usually
follows the line "but multi-threaded code is hard!". It's true,
multi-threaded code isn't trivial. But it's no more trivial to ensure
that code that uses DoEvents() is correct. Just learn how to do correct
multi-threaded code and forget you ever knew about DoEvents().

The fact is, .NET offers the BackgroundWorker class, which is a very
convenient and easy-to-learn approach to avoiding the need for
DoEvents(). It doesn't work for every case, but it does in the vast
majority. For the cases where it doesn't work, there's likely even more
reason to avoid DoEvents() (for example, an architecture where the
application never exits the loop that is calling DoEvents() over and
over), and so even though one can't use BackgroundWorker, it's even more
important to find a more appropriate solution than calling DoEvents().

Pete

 

[Jon Skeet [C# MVP]]

Sorry to interrupt, but you assert here that calling DoEvents is a bad
thing to do. Why is that?

It's almost always a sign that you should be using a different thread
instead. It introduces potential re-entrancy issues, too.