BackgroundWorker vs. Threads

  • Thread starter Thread starter techfuzz
  • Start date Start date
T

techfuzz

I am trying to use a BackgroundWorker, but I need to be able to call
other functions and procedures from within DoWork. I get an error
when I try to do this so I'm lead to believe it is not possible. Is
it possible? If so, how? If not, would using Threads be the
solution?

Thanks,
techfuzz
 
Hello techfuzz,
I am trying to use a BackgroundWorker, but I need to be able to call
other functions and procedures from within DoWork. I get an error
when I try to do this
Click to expand...

It is definitely generally possible to call other methods from the DoWork
event handler - there must be something special about your situation if
you're seeing an error. It would help to know what that error was to judge
what the problem may be.

Both with the BackgroundWorker and with your own threads you have to be
careful about certain calls into existing functionality, and calls that do
anything at all with UI elements are particularly problematic. While your
situation may change when going a different way about your background
processing, you'll most likely encounter similar/different problems if you
don't take the necessary care. The general guideline for the
BackgroundWorker is in fact this:

You must be careful not to manipulate any user-interface objects in your DoWork event handler. Instead, communicate to the user interface through the ProgressChanged and RunWorkerCompleted events.

BackgroundWorker events are not marshaled across AppDomain boundaries. Do not use a BackgroundWorker component to perform multithreaded operations in more than one AppDomain.

(Taken from
http://msdn2.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx
..)


Oliver Sturm
 
Oliver,

I believe I was trying to get the selectedvalue from a UI element. I
don't believe I was actually trying to change anything in the UI, but
just read a value from it. Anyways, I have sorted out the problem by
rewriting some of the functions and procedures and I am no longer
getting the error and my application runs as it should now. Thanks!

techfuzz
 
BackgroundWorker is a class that runs in a separate thread. So either way,
you're working on a separate thread from the UI thread, so you're better off
going with the BackgroundWorker functionality, which is designed to
integrate with the STA Windows Forms environment. The problem in either case
is marshalling to the UI thread.

When the BackgroundWorker class's thread calls a method, or does anything
else with the Form, it is doing it in the context of its' own separate
thread. So, the BackgroundWorker's DoWork method cannot call any methods or
touch anything in the UI thread. However, it CAN raise events, and in your
case, you want to call the ReportProgress(int, object) method. This passes a
ProgressChangedEventArgs instance to the UI thread in the event. The UI
thread can then call whatever methods or change whatever properties it needs
to from there.

The trick is to use the overload of the RunWorkerAsynch method that takes an
object as a parameter. You can pass data to the BackgroundWorker via this
parameter, and when it calls ReportProgress, it can pass the modified data
back. This enables the BackgroundWorker to "communicate" with the UI thread.
Here's an excellent example:

http://www.mikedub.net/mikeDubSampl...eallySimpleMultithreadingInWindowsForms20.htm

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

The shortest distance between 2 points is a curve.
 
Reading or setting doesn't actually matter. If the method or property sends
message to the underlying native control you cannot use it in a thread
different than the UI thread created the control.
 
Back
Top