Showing a progress UI with the option to cancel doesn't require
a seperate thread, and usually doesn't use one unless you want
to get fancy with AVI animations like Windows file copy.
If the operation involves some kind of loop or the 'atomic' operation
exposes some kind of event that's fired routinely during the process,
then the UI can be updated from the loop or event handler.
That's quite commonly how it's done, because in the overhwelming
number of cases I've seen, progress UIs are blocking (e.g., the user
must either wait or cancel, but can't do anything else).
OTOH if this is more an 'adventure in programming' or threading for
threading's sake, then that's another matter, but the fact remains
the the problem is easily solvable without threading.
That's the end goal, to process a request that, when is firing on all cylinders, takes 3 - 5 seconds and then opens the drawing. There are times, however, that it could take much longer, and I need to give the user feedback on progress as well as provide an option to cancel the request altogether. I certainly have no desire to blow the user away, well, at least not most of them
I don't think it's a good idea to simply blow the user away by switching to a newly opened document while they may be in the middle of doing just about anything (like dragging objects around, or perhaps have another dialog box open, or what have you).
In this instance, I agree.
This is not what I was reading into Bobby's original post. Having some type of background threading is a necessity if you are dealing with backend data sources. I read into Bobby's post that he wanted a long process to run then open a file and use a thread so the user could cancel the operation ...].