In your DoWork event handler for the BackgroundWorker (which is where the background work takes place) there is an argument DoWorkEventArgs. This object has a public property object Result. When your worker has generated its result (in your case, a List<FileInfo>), set e.Result to that, and return. Now that your BackgroundWorker has completed its task, … Read more
BackgroundWorker derives from Component. Component implements the IDisposable interface. That in turn makes BackgroundWorker inherit the Dispose() method. Deriving from Component is a convenience for Windows Forms programmers, they can drop a BGW from the toolbox onto a form. Components in general are somewhat likely to have something to dispose. The Windows Forms designer takes … Read more
Instead of using one ParseFiles method (which should depend on myBGWorker) use loop and method which parse one file. Report progress percentage in that loop: private void parseButton_Click(object sender, EventArgs e) { parseButton.Enabled = false; myBGWorker.RunWorkerAsync(); } private void myBGWorker_DoWork(object sender, DoWorkEventArgs e) { for(int i = 0; i < filesCount; i++) { ParseSingleFile(); // … Read more
If the operation raises an exception that your code does not handle, the BackgroundWorker catches the exception and passes it into the RunWorkerCompleted event handler, where it is exposed as the Error property of System.ComponentModel.RunWorkerCompletedEventArgs. If you are running under the Visual Studio debugger, the debugger will break at the point in the DoWork event … Read more
My preference for this is to handle this via a single WaitHandle, and use Interlocked to avoid locking on a counter: class Program { static void Main(string[] args) { int numThreads = 10; ManualResetEvent resetEvent = new ManualResetEvent(false); int toProcess = numThreads; // Start workers. for (int i = 0; i < numThreads; i++) { … Read more
This is not possible, BGW uses a threadpool thread. TP threads are always MTA, it cannot be changed. You will have to use a regular Thread, call SetApartmentState() before you start it. This thread also should pump a message loop, call Application.Run(). Maybe you ought to consider calling this code from the UI thread. Because … Read more
First read this: Use of Application.DoEvents() So after reading the above answer you will never using DoEvents ever again, and without the DoEvents (and/or Invalidating the ProgressBar so its Paint event will fire) the “progressbar won’t animate since the upgrade process is so intensive” Hence Cthulhu’s comment – “You can make a dialog with a … Read more
There’s a lock inside GDI+ that prevents two threads from accessing a bitmap at the same time. This is not a blocking kind of lock, it is a “programmer did something wrong, I’ll throw an exception” kind of lock. Your threads are bombing because you are cloning the image (== accessing a bitmap) in all … Read more
What you’re describing is not the defined behavior of BackgroundWorker. You’re doing something wrong, I suspect. Here’s a little sample that proves BackgroundWorker eats exceptions in DoWork, and makes them available to you in RunWorkerCompleted: var worker = new BackgroundWorker(); worker.DoWork += (sender, e) => { throw new InvalidOperationException(“oh shiznit!”); }; worker.RunWorkerCompleted += (sender, e) … Read more
You can use something like this (for more information about aborting managed threads and about ThreadAbortException see “Plumbing the Depths of the ThreadAbortException Using Rotor (Web archive)” by Chris Sells): public class AbortableBackgroundWorker : BackgroundWorker { private Thread workerThread; protected override void OnDoWork(DoWorkEventArgs e) { workerThread = Thread.CurrentThread; try { base.OnDoWork(e); } catch (ThreadAbortException) { … Read more