SOLVED - PLEASE SEE COMMENTS BELOW IF YOU ARE INTERESTED IN HOW THIS WORKED OUT, SINCE IT IS A 2-PART SOLUTION, BOTH OF WHICH ARE POTENTIALLY USEFUL TO OTHERS.
Often, users will go to my program's "import data" window to initiate an import of data from a file or spreadsheet to our database. Depending on the size of the import, though, this can take up to 2 minutes.
Therefore, to reduce this time, I have decided to get a head start on the predictable aspects of the import process during program initialization, by using a BackgroundWorker
.
As the data import progresses, the data import classes are busy raising the BackgroundWorker.ReportProgress
event, passing in a state object in the ProgressChangedEventArgs
. The state object has all the data to show a ProgressBar
and some other state like number imported, an icon, popup message, etc., but there is no UI (yet) to display this progress.
But then if the user is quick enough, they can get to the "import data" window before the background import is done. It is still in progress in the BackgroundWorker
.
So when that window loads, I "tune in" to the state of the import process, by handling the ProgressChanged
event of the BackgroundWorker. This keeps the user amused while the process completes.
By the way: Since this is a Windows Forms application, I can tell you that I have had lots of trial-and-error fun with cross-thread errors trying to update UI controls from the BackgroundWorker thread. I finally gave up on all that and decided to try and use the ProgressChanged
event instead.
Back to the sad story: However, at this point, the user may now decide to re-import, or change some properties that were preventing the success of the import, and proceed to initiate the import "manually", as they used to do before I implemented this BackgroundWorker
idea.
So now the program is doing another data import, and of course I want to use the same classes that the BackgroundWorker
used, but this time, it's going to be done in the UI thread.
So the BackgroundWorker.ReportProgress
event that my import classes were raising to the BackgroundWorker
need to be handled instead by the UI thread.
I have this foggy notion that a Delegate
could be used to report progress to either the UI thread or the BackgroundWorker
thread, but I don't have a lot of experience with using them.
So here's my question: How can I use a Delegate
to send this progress to the BackgroundWorker
if it's running, but to the UI if the process is initiated there?
Or, do I need a to abandon the BackgroundWorker idea and teach myself how to use something like the more complicated Event-based Asynchronous Pattern
as explained in the MSDN article entitled "Event-based Asynchronous Pattern Overview"?