Hey,
I think you should check out the standard .NET component called BackgroundWorker. It makes life quite easier when dealing with simple multithreaded progress reporting tasks.
Ahh... a worker thread. Cool - we'll look at it, thanks.
You're welcome 
Forgot to mention - in case you've got a chance to lay your hands on the freshly baken
Windows Forms 2.0 Programming
By Chris Sells, Michael Weinhardt
its Chapter 18 "Multithreaded User Interfaces" gives a neat walk-through.
Hmmm,
I would be a little nervous about adding threading as a result of user stories rather than as a result of some high level architectural thinking.
Threading is *really* easy to get *wrong* if you just do it in an adhoc way. Making an unholy mess with threads here and mutexes/locks there and no clear picture is the way many an application has gone.
This was one of the lines of thinking behind my questions on architectural design authority when I visited you guys....
Giles (the gaffer) has a very good eye for architecture.
Every couple of weeks we get round a white board and discuss it, usually resulting in a refactor.
The object model of Resolver now is pretty good, with well defined dependencies and relationships. It's about due for another refactor due to the changes we've been making since the last one.
The thread that we've introduced here is contained within a single class - and is almost exclusively used within it.
It is only accessed 'externally' by two places. One of which uses the old (unchanged) synchronous API and the other we've changed to use the new one. Especially using the BackgroundWorker it is very clean and integrates well. (No need for mutexes - and I don't think it deserves the ad-hoc epithet.)
Given the user story I don't think we have a lot of choice, and I like our solution. As it is well contained it will be easy to revert if Giles disagrees !
Commenting by HaloScan
