Because we took the step of setting the WorkerReportsProgress property to True, we can harness this to, well, report progress actually! 

  There are several ways we can keep the user informed.  Often a ProgressBar will be used and updated as the task reaches various stages.  Although we could take this route for the current project, calculating an exact count or time estimate for the task can sometimes be tricky, so I decided just to go feedback that displayed the files in a listbox as they are found.   Later I'll add some simple code that gives a clearer indication that the process is still working. 

  For additional user clarity I thought that what I would do is to create a new form as soon as the BackgroundWorker starts its task and get it to report progress directly back to this form.  (As opposed to displaying on the form I used to create and control the BGW ).

  This way, the user can minimise the form that shows progress if they want to so that the progress state isn't constantly in their face.

  So the next step will be to create a second form, called  frmProgress and to place a large ListBox on it.  (You could fill the whole form with the ListBox if you prefer, but I plan to add a label later to give the user more feedback, so have left some space at the bottom of the form).  

  Outside any of the form's procedures declare a variable for a frmProgress:

  The reason for doing it this way is that you will want to refer to this frmProgress  instance from elsewhere in Form1, so you need the scope to be form wide.

  Now you can instantiate a new frmProgress from the click event of the start button:

   I found that I really wanted the progress form to be placed neatly to the right hand side of Form1, so I also added this optional code to the button's click event:

 which takes care of that.  Well, it should, but if you find that the progress form stubbornly insists of plonking itself on top of the calling form then you'll  need to either change the StartPosition property in the Properties Window or add this further line of code:

  Next we need the code that will actually send the feedback to this form.

  If you refer back to the screenshot that showed the events available for the BGW you will see there is one named ProgressChanged.  This is the procedure in which we will place the code that actually updates the ListBox. 

   However if you make this edit and run the project however you won't be rewarded with a display of files in the ListBox;  a result which may or may not surprise you.  

    The reason is that the above event will only fire when it is informed that there has in fact been a change of some kind that is classifed as a change in progress.  So what is needed is a trigger elsewhere which will cause this event to fire.  That trigger is the ProgressChanged method of the BackgroundWorker which in this example we will place inside the FileFinder procedure.

  Here is the amended code for this requirement:

  You will see that the ReportProgress method has two parameters - an Integer and also what appears to be a String.  The second parameter is in fact an Object, but as we have already declared fname as a string, this is the type that will be passed to the event.

  The first parameter is PercentProgress and you can assign a value to this to represent how far the process has moved through the task.  As I mentioned earlier, I've chosen not to implement this feature so I pass back a value of zero each time.   If you decide that you do need this for a project of your own, then you simply calculate the percentage at any given moment, assign this value to PercentProgress and use it in the ProgressChanged event as you wish (e.g. as a means of updating a progress bar).   

  The second parameter is UserState.  In this example I have chosen to assign the string that is the name of each file found to UserState.   Because ReportProgress runs each time the FileFinder succeeds in finding a file that meets the criteria, this of course means that all matching file names will be passed back in turn and can be listed in the ListBox.

   I hope that all makes sense.  You may be wondering at this point why it is necessary to take this long way round the task.  Why not simply add code such as:

to the FileFinder procedure in order to update the ListBox?

  If you are curious I suggest you try it.   As you will see, the problem is that because you are now running the application using two separate threads the background thread can't "see" the main thread and so has no direct knowledge of the progress form and its ListBox.   The BackgroundWorker has to play that middleman role in order for the two threads to be able to communicate data between each other.

   As a matter of usability, one thing I don't particularly like about the way the ListBox is populated is that once its visible height is filled with file names, there is little indication that something is still happening.  In fact, the vertical scrollbar changes size as the list lengthens but this isn't particularly obvious.   So I will make some minor improvements to deal with this.

  First, try adding a new line to the ProgressChanged event as shown below:

Then run the project again.

   This time it's very obvious that the process is working away.   In fact, you might even think it's too obvious and might dislike the way the highlight flashes on and off as it updates.  If so, you can add yet another line:

and this will fix that issue.  If you download the sample solution that I have included with this article you'll see that I have also added a label that gives the user some additional feedback.

  When you run this project now, you can check that the main thread (and your Form1) is fully accessible to the user by, for example, simply moving the form around the screen in the usual way - something you wouldn't be able to do if the project was choked up on the long running task.  

  Again, in the sample solution I have included a better means of checking that everything is running smoothly.  At the click of the Start Button, a third form is instantiated and shown and this form contains a calendar and a label.  The user can access the calendar and will see feedback from their actions.  This will happen while the ListBox on the progress form still continues to be updated.