Comments on: .NET Basics – Do Work in Background Thread to Keep GUI Responsive

By: Shane

Shane — Wed, 20 Feb 2013 21:15:57 +0000

Thanks for the quick response Sean and yes you understand me correctly, except to add that a form button does not directly create the loop. A button does start the process, but the loop starts within an object of another class, that I instantiate from my main form. This object is my work-engine type object…it does a whole load of checking, before looping through a list of ‘items’.
I’ll come clean; the ‘items’ are software applications that I want to install sequentially. Some are Windows Installer\MSI based, and for this I use a windows installer API DLL that seems to work asynchronously, raising events which are handled in my main form (not my code btw) to update progress bars etc. The remainder are exe based setup routines.
These exe based routines need their own async process…so, I did previously think about placing the entire loop into its own background worker, as you said, but I’d decided that it would be complicated as I’ll now be calling MSI’s which already run asynchronously, from another asynchronous thread – queue lots of head scratching wondering how the communication back to my main form is done – but perhaps this is not as complicated as I think?
Currently, to get around my issue, I’m resorting to using Process.Start for all non-MSI applications, running theses with a reduced GUI of their own (if they support this natively) and hiding my main form so that a user can’t click on it and discover it’s frozen\busy – not pretty but gets me there.
.Net 4.0 is not allowed in our current environment unfortunately.

I need to do some more reading I think. TBH, I’ve only started coding in the last year so there’s a lot I need to learn.
Once again, thanks for the response.

By: Sean

Sean — Wed, 20 Feb 2013 19:01:14 +0000

Thanks Shane. If I understand you correctly, you want to have the user click on a button and then work through a loop, doing some action iteratively. And you want the GUI to not block, but become immediately responsive after they click the button?

I would just put the entire for loop in the BackgroundWorker and then, each time through the loop, do the work you’re doing synchronously, rather than firing up a BackgroundWorker for each iteration. You’d only do this if you wanted them to run in parallel.

Even better, you should probably look into using async/await keywords, available in .NET 4.5. (Or .NET 4.0, using Async Targeting Pack). They simplify the pattern for doing asynchronous work on background threads, even a bit more than the BackgroundWorker.

By: Shane

Shane — Wed, 20 Feb 2013 13:06:58 +0000

Excellent post. I had to struggle through other backgroundworker tutorials on the web – why couldn’t I have found this one first!

I have a question Sean if you don’t mind – once you fire off a backgroudworker, it does its job asynchronously. As a form button was used to kick start this whole process, control returns to the form which is now free from the time-consuming activities and thus does not freeze. And no other form code is executed until a user clicks on another enabled button etc.

But what if when you click on a button you have a for or while loop, and in this loop you want to call a background worker. But you do NOT want the next loop iteration to execute, until the background worker has completed its first task? Can this be done? i.e. can you somehow pause the next loop iteration while the background worker is doing its thing, but not freeze the main form?

By: M.S.

M.S. — Mon, 19 Nov 2012 18:39:33 +0000

a nice, clearn article about the subject explaining everything in detail. this is hands down the most educative article on threading I’ve seen to date. Even my primary reference book (Pro c# 2008) lacks clarity on the subject and does not explain it in such layman’s terms as this article does. kudos to the author for keeping it simple.

By: Andy Wawa

Andy Wawa — Sat, 13 Oct 2012 19:22:58 +0000

Hi Sean,
the difference is much bigger than just a byte: let’s say I’m reading a Word-Doc (Word 2007), I get: totalBytes=30720 and bytesRead=37098…
Maybe it’s just an academic problem with FileInfo vs. StreamReader, the goal of your tutorial was the function of the BackgroundWorker and after I’ve worked through this, I finally understood.

Andreas

By: Sean

Sean — Fri, 12 Oct 2012 15:32:34 +0000

Hmm, interesting. What is bytesRead at that point, vs. totalBytes? Just 1 byte too many? You could also comment out the pctComplete stuff and let the loop complete (read until ReadLine returns null) to see how many bytes the StreamReader is telling you it read. Is it just a byte or two beyond what FileInfo said was in the file? Or is it much higher? Perhaps there’s a problem in my logic related to assumptions about encoding, i.e. FileInfo vs. StreamReader

By: Andy Wawa

Andy Wawa — Fri, 12 Oct 2012 13:04:10 +0000

Hi Sean,
as I already said, an excellent article!
Still there is something I don’t quite understand: while reading a “simple” text file it all works fine. But reading a Word-Doc I get an ArgumentOutOfRangeException saying, that the value
(ReadTheFile class): int pctComplete = (int)(((double)bytesRead / (double)totalBytes)*100); > 101 % is!
It means, that bytesRead > totalBytes..(and it really is).
Does the programm count some hidden characters?

Andreas

By: Sean

Sean — Thu, 11 Oct 2012 01:58:18 +0000

That should be fine. If the thread is terminating, likely it’s throwing an exception.

By: Steven

Steven — Thu, 11 Oct 2012 01:53:33 +0000

Have you ever tried setting up a TCP/IP client in a Background Worker. It seems that if I spend too long processing data coming in, the thread terminates prematurely.

By: Background thread | Bigappletowing

Background thread | Bigappletowing — Thu, 03 May 2012 06:35:48 +0000

[...] .NET Basics – Do Work in Background Thread to Keep GUI …May 21, 2009 … A well designed application, on the other hand, is one that is careful to do as much work as possible in background threads, keeping the GUI … [...]

By: Sean

Sean — Wed, 21 Dec 2011 13:44:45 +0000

Take a look at – http://www.albahari.com/threading/ for a good intro to threading.

By: hollidevil

hollidevil — Wed, 21 Dec 2011 07:12:07 +0000

Excellent work…can you provide links where I could study in depth about Threads and their types and all..
Thanks

By: » Suplanus

» Suplanus — Fri, 07 Oct 2011 17:30:22 +0000

[...] Quelle: stuff.seans.com Drucken [...]

By: Gold Post

Gold Post — Fri, 01 Jul 2011 01:23:33 +0000

Andreas,
It is not a good idea to use he finally block for normal code execution. Exceptions are for errors. Also, when an exception is thrown, the performance of the app stinks.

Sean,
Great article!

By: Andreas Wawa

Andreas Wawa — Thu, 26 May 2011 11:59:15 +0000

Thanks Sean for your excellent work!!
Simply put: when I’ve a button fireing several Methods in row(gathering infos, copying files (some 2 GB, i takes time..), installing, doSomeScripts, another_install etc.) and EVERY single method MUST wait for previous one to be acomplished (there is no point in installing when the files still are not copied!) all what I need to do, is just put then next method (say after copying the next one is installing()) in finally-block of “bgWorker_RunWorkerCompleted” method??
Andreas

By: Ram

Ram — Tue, 08 Mar 2011 18:15:38 +0000

I agree with all of the other poster’s comments – this is by far the best threading tutorial dealing with unresponsive UI that google search could bring up. I waded through several links but persistence paid of and found this gem that you have created on the second page full of links!
I am trying to build a Windows front end that captures sensor data via Ethernet/UDP and display it dynamically in a GUI, and I am confident that the knowledge gained from your article will help me greatly. Thank You!

By: Albert

Albert — Wed, 30 Sep 2009 17:56:08 +0000

p.s.s. also i’m doing something funkier with the _ProgressChanged(object sender, ProgressChangedEventArgs e) function:

the ProgressChangedEventArgs e object has a property called e.UserState which is an object.

I’m using this backgroundworker in an app where I am sending an Image to a ListView for display as it finds the Images on disk. So I am actually passing the Image object to the ProgressChanged handler by passing the Image as a (object) through the e.UserState !

then my progresschanged handler function casts it back to (Image) and adds it to the ListView.LargeImageList

and it works! and it works pretty fast too! so just a tip since e.UserState is an (object) you could pass almost anything through it and cast it back at the UI thread’s handler function.

By: David

David — Wed, 30 Sep 2009 15:43:32 +0000

Thanks Sean, I had always been aware of doing things in a background thread being a good practice with windows forms but was daunted by the idea of turning an otherwise simple app multi-threaded. Thanks to your examples I don’t have to be further disgusted by my overuse of application.doevents(). Much appreciated!

By: Sean

Sean — Thu, 24 Sep 2009 22:15:23 +0000

Thanks Albert. Good question (why). My quick guess is that the underlying Win32 controls are not thread-safe, so we have to appoint a single thread to do all of the updates. But I’d like to dig a little bit deeper to also understand the lower-level aspects of what’s going on. Stay tuned–sounds like a good topics for a future post.

By: albert

albert — Thu, 24 Sep 2009 21:42:31 +0000

This is the best UI multithreading tutorial on the web I have found yet. Everyone else’s tutorial is horrible. This one here is the most concise, most descriptive, most easily understandable. I feel like all the other tutorials are just copying off eachother and no one knows how to explain it well. Thanks for writing one that finally explains it well.

P.S. No one has explained *why* a form control can never be updated from outside the UI thread. Why can that never happen? Is it just a security measure .net has to prevent controls from being manipulated by viruses or other programs?

By: Dirk

Dirk — Fri, 24 Jul 2009 12:24:11 +0000

Thanks mate!

By: Batul

Batul — Thu, 25 Jun 2009 15:40:00 +0000

Thanks a lot. This post is really useful. I started as a novice in threading… but got my application working. Many many thanks.