BackgroundWorker + CF 2.0

[Guest]

Hi,

I'm trying to use the BackgroundWorker class from OpenNetCF SDF 1.4 in a CF
2.0 app, getting some very unexpected behaviour. So firstly, I need to
confirm my understanding of how things are supposed to work:

I perform 'work' on inside the DoWork event handler, not referencing any UI
components. The DoWork event is raised on another (background, non UI)
thread. As I perform 'work' I can use the ReportProgress method from inside
the DoWork event handler which will raise the ProgressChanged event on the UI
thread sometime later. Then once the DoWork event handler has returned, the
RunWorkerCompleted event will fire.

I'm finding that the only way things work as expected is if I *only* make
calls to ReportProgress inside the DoWork event handler. As soon as I do
ANYTHING else (eg Console.Out or construct a new object), the
RunWorkerCompleted event fires, and no further code inside the DoWork event
handler are executed. So if I have 10 lines of code, the first line of code
will execute, then the RunWorkerCompleted event fires, and no further lines
of code run.

I've been testing this with breakpoints which at first I suspected would be
adversly affecting things, but even when I compile with my second line of
'work' code being a simple 'throw new Exception()' and run the app outside of
VS I can see this second line of code never runs.

I'm using the PRO version of VS 05 on an XDA II device.

Anyone share this experience or have any ideas? I would dearly love to use
this class instead of the usual mess I make running 'long running work' in
the background... Thanks in advance.

 

[Daniel Moth]

Can you post a sample so I can try it out?

BTW, a sample showing how you should be using the BW is here:
http://www.danielmoth.com/Blog/2004/12/backgroundworker-sample.html

Cheers
Daniel

 

[Guest]

Daniel,

Thanks for the reply and sorry I took so long to get back.

After finally having some more time to look at the problem it seems like I
only get progress events *after* the completed event when exceptions are
thrown from the worker thread. Does that make sense, and is that to be
expected?

In the test I just performed I get 3 of my progress updates after the
completed event is called.

The basic jist of what I'm doing to get this behaviour is as follows.

ReportProgress("First");

// do stuff

ReportProgress("Second");

// do stuff

// repeat above a few times

throw new Exception("Blah"):

It sounds quite strange but I didn't get this behaviour on the VS 05 PPC SE
Emulator, only my XDA II device???

I have my own 'Worker' abstract class from which I raise progress events
from the DoWork method. So I've found a 'solution' (works for me, might not
be desired in all cases): I call Thread.Sleep(0) after I raise my progress
event (therefore Thread.Sleep(0) is called on the worker thread). This way
the Progress events seem to be processed straight up, which in my particular
case is what I prefer.

public abstract class Worker : IProgressReporter
{
public abstract void DoWork(DoWorkEventArgs args);
public abstract bool ReportsProgress { get; }
public abstract bool ReportsPercentComplete { get; }
public abstract bool SupportsCancellation { get; }

public event ProgressChangedEventHandler ProgressChanged;

public void ReportProgress(string progress)
{
if (ProgressChanged != null)
{
ProgressChanged(this, new ProgressChangedEventArgs(-1,
progress));
Thread.Sleep(0);
}
}

//2 more ReportProgress overloads here...
}

So everything works exactly how I want it to. Thanks very much for
implementing this beautiful class for us. It's so much nicer than me using
Control.Invoke everywhere in a really messy way.

I have a pretty hefty app framework built, so if you want to see my app as
an example I'm happy to email you my entire solution, but I won't be able to
paste the code into a post. You can let me know directly at
(e-mail address removed) if you like, I'm totally happy to do so if
required.

Cheers,
Sam.