[RESOLVED] 2005 - Problem with Backgroundworker and UI

[conniek]

I have an grid for displaying email retrieved from a pop email account. The headers are retreived one at a time using a backgroundworker. It supplies a datarow to the main thread with the new email data. The datarow is added to the grid datasource which is a datatable. From the user's perspective, one new row at a time is added to the grid until all emails are retrieved.

Except for users with very fast pop servers. For them, the grid is not refreshing quickly enough to keep up with the background worker supplying new rows. They end up seeing rows of the same data duplicated over and over and skipped rows. I tried using a thread monitor and it's not working. The only thing that worked was setting a 1 second join on the backgroundworker, and this isn't a solution since it slows everyone down, even the already slow connections, instead of solving the issue. Why can't a grid keep up with the data being supplied. Is there a better way to provide the data to the grid?

It's easy to test with a simple application. Add a datagrid, a backgroundworker and a button to a form. Add this code to the form:

    Private ds As New DataTable
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        BackgroundWorker1.WorkerReportsProgress = True
        ds.Columns.Add("Row Number", GetType(Integer))
        DataGridView1.DataSource = ds
        Dim cls As New Class1
        BackgroundWorker1.RunWorkerAsync(cls)
    End Sub
    Private Sub BackgroundWorker1_DoWork(ByVal sender As System.Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles BackgroundWorker1.DoWork
        Dim worker As System.ComponentModel.BackgroundWorker
        worker = CType(sender, System.ComponentModel.BackgroundWorker)
        Dim cls As Class1 = CType(e.Argument, Class1)
        cls.GetData(worker, e)
    End Sub
    Private Sub BackgroundWorker1_ProgressChanged(ByVal sender As Object, ByVal e As System.ComponentModel.ProgressChangedEventArgs) Handles BackgroundWorker1.ProgressChanged
        Dim state As Class1.CurrentState = _
       CType(e.UserState, Class1.CurrentState)
        ds.ImportRow(state.dr)
    End Sub

Then also add a class to the project:

Public Class Class1

    Public Class CurrentState
        Public dr As DataRow
    End Class

    Public Sub GetData(ByVal worker As System.ComponentModel.BackgroundWorker, _
            ByVal e As System.ComponentModel.DoWorkEventArgs)

        Dim dr As DataRow
        Dim state As New CurrentState
        Dim table0 As New DataTable
        table0.Columns.Add("Row Number", GetType(Integer))
        dr = table0.Rows.Add

        For x As Integer = 1 To 50
            dr.Item("Row Number") = x
            state.dr = dr
            worker.ReportProgress(0, state)
            System.Threading.Thread.CurrentThread.Join(10)
        Next

    End Sub

End Class

Play with the CurrentThread.Join timeout when you run the project. Notice that if you set it to a very low number, the grid does not give you a sequential row numbering. It skips and repeates row numbers. That simulates a fast pop server turning data to the grid very quickly. Set a high timout, and there is no problem. That simulates a very slow pop server and the UI is able to keep up with the data being supplied to it. If I add a SyncLock or Monitor.TryEnter, it never stops thread supplying data and the grid still does not update correctly. I get the exact same results.

If I arbitrarily decide to have my application set a high timeout, my users with fast pop servers are going to start screaming because their fast email is now crawling. Is there a better solution?