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
CancelAsync doesn’t actually abort your thread or anything like that. It sends a message to the worker thread that work should be cancelled via BackgroundWorker.CancellationPending. Your DoWork delegate that is being run in the background must periodically check this property and handle the cancellation itself. The tricky part is that your DoWork delegate is probably … Read more
You can update progress bar only from ProgressChanged or RunWorkerCompleted event handlers as these are synchronized with the UI thread. The basic idea is. Thread.Sleep just simulates some work here. Replace it with your real routing call. public Form1() { InitializeComponent(); backgroundWorker1.DoWork += backgroundWorker1_DoWork; backgroundWorker1.ProgressChanged += backgroundWorker1_ProgressChanged; backgroundWorker1.WorkerReportsProgress = true; } private void button1_Click(object sender, … Read more
The Task class is an improvement over the BackgroundWorker; it naturally supports nesting (parent/child tasks), uses the new cancellation API, task continuations, etc. I have an example on my blog, showing the old BackgroundWorker way of doing things and the new Task way of doing things. I do have a small helper class for tasks … Read more
If I understand your requirement right, you could do something like this (code not tested, but shows the general idea): private BackgroundWorker worker = new BackgroundWorker(); private AutoResetEvent _resetEvent = new AutoResetEvent(false); public Form1() { InitializeComponent(); worker.DoWork += worker_DoWork; } public void Cancel() { worker.CancelAsync(); _resetEvent.WaitOne(); // will block until _resetEvent.Set() call made } void … Read more
You start it like this: int value = 123; bgw1.RunWorkerAsync(argument: value); // the int will be boxed and then private void worker_DoWork(object sender, DoWorkEventArgs e) { int value = (int) e.Argument; // the ‘argument’ parameter resurfaces here … // and to transport a result back to the main thread double result = 0.1 * value; … Read more
Some of my thoughts… Use BackgroundWorker if you have a single task that runs in the background and needs to interact with the UI. The task of marshalling data and method calls to the UI thread are handled automatically through its event-based model. Avoid BackgroundWorker if… your assembly does not have or does not interact … Read more
This is likely TL;DR for many, but, I think comparing await with BackgroundWorker is like comparing apples and oranges and my thoughts on this follow: BackgroundWorker is meant to model a single task that you’d want to perform in the background, on a thread pool thread. async/await is a syntax for asynchronously awaiting on asynchronous … Read more
Add using using System.ComponentModel; Declare Background Worker: private readonly BackgroundWorker worker = new BackgroundWorker(); Subscribe to events: worker.DoWork += worker_DoWork; worker.RunWorkerCompleted += worker_RunWorkerCompleted; Implement two methods: private void worker_DoWork(object sender, DoWorkEventArgs e) { // run all background tasks here } private void worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) { //update ui once worker complete his work } … Read more
This is a common problem with people getting started. Whenever you update your UI elements from a thread other than the main thread, you need to use: this.Dispatcher.Invoke(() => { …// your code here. }); You can also use control.Dispatcher.CheckAccess() to check whether the current thread owns the control. If it does own it, your … Read more