Prev: transferring native DLLs in "Publish Web Site"
Next: Control instance from different framework version.
From: Peter Duniho on 19 Apr 2010 11:29
Tom P. wrote:
> [...]
> I look at IsBusy and if I need to I set a restartSetPath flag and then
> CancelAsync().
> In RunWorkerCompleted if this was Cancelled then I call DoSetPath from
> there.
>
> Works like a charm.
>
> I knew there was a right way to do this.

Glad you got it to work.

Note: be very careful to _only_ to the IsBusy check in your GUI thread,
the same one where your RunWorkerCompleted event handler will be
executed. Without doing that, you'd have a potential race condition in
which you set your "restartSetPath" flag but only after the
RunWorkerCompleted event handler executes, thus causing the flag to not
be handled correctly in the event handler.

As long as you do all of your controlling logic of the BackgroundWorker
in the main GUI thread where the BackgroundWorker was created, there
should be no problem. This is the normal, likely usage pattern for
BackgroundWorker anyway, so your code is already doing it that way.

Pete
From: Patrice on 19 Apr 2010 11:33
> Actually, since BackgroundWorker uses the thread pool you very much
> can start RunWorkerAsync() even if the BackgroundWorker is busy.

From http://msdn.microsoft.com/en-us/library/h01xszh2(v=VS.80).aspx :

"If the background operation is already running, calling RunWorkerAsync
again will raise an InvalidOperationException."

And this is what I alway saw...

> The problem is not how to start the BackgroundWorker again, rather,
> how to interrupt the old one and wait until it's finished.

Have you tried Peter's or my own code sample ? Feel free to ask a specific
question if you still have issues... (both codes are using CancelAsync and
let the Completed even to happen rather than looping).

--
Patrice

First  |  Prev  | 
Pages: 1 2 3
Prev: transferring native DLLs in "Publish Web Site"
Next: Control instance from different framework version.