From: Bjørn Brox on
Erivis skrev:
> Found it. Application.DoEvents() did the trick
> Erik
>
That is definitely not a recommended action.

--
Bj�rn Brox
From: Jeff Johnson on
"Erivis" <erivis(a)nospam.com> wrote in message
news:%23z5DcrTELHA.4068(a)TK2MSFTNGP06.phx.gbl...

>> Move it to another thread which reports the progress back to the main
>> thread.

> Thanks for your suggestion.

For reference, it's not just a suggestion; it's the absolute best solution
to the problem.


From: Peter Duniho on
Erivis wrote:
> Arne
>
> > Try and see how many hits Google gives on
>
> you must refer to this:
> Q: DoEvents is evil?
>
> A: Glenn (Microsoft) Yielding on the UI thread is a legitimate Windows
> programming practice. It always has been. DoEvents makes it easy,
> because the situations in which you need to use it are simple

I find it ironic that the only places I find that quote are web page
where the primary theme is in fact "don't use DoEvents()", if not
literally "DoEvents() is evil".

If you're going to provide a quote, you should also provide context:
http://www.codinghorror.com/blog/2004/12/is-doevents-evil.html
http://social.msdn.microsoft.com/Forums/en-US/vblanguage/thread/bf605ecb-9b2f-4d1a-915f-8280f14629bf
http://www.daniweb.com/forums/showthread.php?t=253288

It is definitely true that DoEvents() is the easy way out. It requires
practically no skill or effort to use. And inasmuch as .NET lowers the
bar for programmer skill and effort, it has its place. There are some
people who simply cannot be trusted with even simple multi-threading
such as that provided by BackgroundWorker.

But that doesn't mean it's the _right_ or _best_ way to do things. It
is a halfway solution at best, and can still leave significant
irregularities and pauses in the responsiveness of one's program. And
really, using BackgroundWorker correctly is hardly much harder, since as
long as you keep your reference type data isolated to either the DoWork
event handler or the "Result" of the RunWorkerCompleted event, you won't
even have to worry about the usual things "real" multi-threaded
programming involves.

Pete