views:

199

answers:

4

I've read a number of examples on using BackgroundWorker objects to handle executing time-intensive tasks which generate results which are used to populate a DataGridView. However in my case it seems as though the act of populating the DataGridView is what's taking the most time. I'm wondering if this is because I need to format the results (hide certain columns, check for certain flags on each row to set the color/font, etc.).

Example:

DataTable results_table;
DataGridView my_grid;
DataView my_view;

private void fillTable()
{
    // Generate the results
    ...


    // Bind the data.
    my_view.Table = results_table;
    my_grid.DataSource = my_view


    // Format the results
    my_grid.Columns[0].Visible = false;
    my_grid.Columns[1].Visible = false;

    my_grid.Columns[2].AutoSizeMode = DataGridViewAutoSizeColumnMode.AllCells;
    my_grid.Columns[3].AutoSizeMode = DataGridViewAutoSizeColumnMode.Fill;

    foreach (DataGridViewRow row in my_grid.Rows)
    {
        // Check for flags and format necessary rows.
    }
}

Is this the right way to go about doing this, or is there some other way to format the results without having to iterate through each row?

+1  A: 

I don't think that multi-threading will help you out here, since any interaction with the control will need to happen on the GUI thread anyway (as Adam points out as well).

Last time I was working with the DataGridView I found that my largest performance bottle neck was the use of AutoSizeMode. Can't remember if it was some specific value that was extra bad, but it really made a bit difference. I would experiment with that property to start with.

Fredrik Mörk
+5  A: 

You can't actually do the formatting in another thread, as all operations that deal with UI elements must take place on the UI thread. The best you could do is do your processing and decision-making up front so that the code that actually interacts with the GUI is as simple and lean as possible.

Adam Robinson
As Fredrik pointed out, the use of the "AutoSizeMode" property (specifically when it was set to "AllCells") was causing the biggest delay. All columns are now set to "Fill" instead, and even with the row-by-row formatting (bold-ing, underlining, etc.) the performance hit is much less significant.
themarshal
A: 

I can't remember if .NET has an option for suspending screen updates while you make a bunch of changes to form controls. If it does, that might speed up your UI changes.

Don Kirkby
A: 

As everybody has mentioned, you can update your UI only from GUI thread. But, what you can do is move the code which creates my_view on a separate thread.

P.K