Question

I’m working in a c# windows application with vs2010 and a local database.In one of my forms i use a BindingNavigator with a group of textboxes filled by the database and a ReporViewer. I’ve added a background worker in order to fill the table adapters in case there are a lot of records in the database.

The problem is that the way I’m using the background worker when i debug my app i cannot see any data in the textboxes, otherwise when i run my app it’s working fine. I know that this is a case of accessing the UI on a non-UI thread and it is wrong. Is there a another way around it?Thank you in advance.

Here is the code I’m using:

private void Client_Load(object sender, EventArgs e)
{
    backgroundWorker1.RunWorkerAsync(); 
}

private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
    this.clientTableAdapter.Fill(this.database1DataSet.Client);
    this.projectTableAdapter.Fill(this.database1DataSet.Project);

    if (InvokeRequired)
    {
        this.Invoke(new MethodInvoker(this.reportViewer1.RefreshReport));
        return;
    }
}

Answer 1

Typically, a background worker returns on the same thread, and would actually throw an exception about the non-UI thread. However, this might be eaten in your case. You should be using the RunWorkerCompleted event for items that are to happen after your main work is done, especially when looking to update the UI. And, this should return to the same thread it was called from (UI in your case) as mentioned above.

So, I would move your UI processing code (RefreshReport) into a new method set up for the RunWorkerCompleted.

However, my suggestion would be to take a look at the Task Parallel Library. It ends up making code much cleaner and easier to debug IMO.

Example (rough and may not compile due to the nulls, but you can get the jist :)):

var task = Task.Factory.StartNew(()=>{//Do Async Stuff});
task.ContinueWith((previousTask)=>{//Do your UI Stuff}, null, null, 
    TaskScheduler.FromCurrentSynchronizationContext);
//The FromCurrentSync makes sure the method returns 
//to the same thread (UI in this case) that it started

I know that is not a direct answer, but more of a suggestion towards what I would consider a cleaner, more debuggable approach.