Hi,
There is a button on a win form which populates a gridview control with data.
to prevent the UI being locked I am using the Backgroundworker.
The application does not get locked when the data is being retrieved, but it does get locked when inside the event "backgroundWorker1_RunWorkerCompleted" on line:
dataGridView.DataSource = e.Result;

Any thoughts on this please?
Thanks

This is because that event is going to do the databinding, and update your DataGridView. Unfortunately, that must stay on the UI thread, since it's updating the DataGridView. It should be a fairly short process, though, since your data source (should be) completely filled in.

There are some times when you can't avoid locking the UI - the trick is just to make the lock as small as possible, which is what you're already doing in this case.

---

Reed Copsey, Jr. - http://reedcopsey.com

To avoid this block of the UI thread, return the data to the UI thread inchunks in the DoWork event through the UserState variable of the ProgressChanged event.

To avoid this block of the UI thread, return the data to the UI thread inchunks in the DoWork event through the UserState variable of the ProgressChanged event.

John,

How does this avoid the block when he assigns the data to the DataGridView's DataSource? At some point, the data has to attach to the control and databind - I think he's just databinding a large enough source that it's generating a block.

Is it possible to databind in stages and avoid this? Moving the data across threads isn't going to cause any delay (since it's not really "moving" the data), and he's already loading the entire dataset (according to his post) in the background thread...

---

Reed Copsey, Jr. - http://reedcopsey.com

You seem to know the definition of e.Result. I don't. A DataGridView is a UI element. Doing just about anything with it shouldn't block the UI thread. If it does, it should be redesigned.

Whythat line throws an exceptiondepends upon where the object e.Result is getting declared.

I have a rule of thumb that seems to keep out of these sort of troubles.
Pay attention to variable scope, and do not reference any variables inside of the thread that were not declared in the thread.
Let's call it thread scope, don't cross the line. Don't reference any variables declared at the class level except for the BGW itself.

Hope this helps.

Rudedog =8^D

---

Mark the best replies as answers. "Fooling computers since 1971."

Hello arkiboys

Apart from others' suggestions, you may also consider using VirtualModeof DataGridView. Virtual mode is designed for use with very large stores of data, to prevent hangs in UI. When the VirtualMode property is true, you create a DataGridView with a set number of rows and columns and then handle the CellValueNeeded event to populate the cells. Virtual mode requires implementation of an underlying data cache to handle the population, editing, and deletion of DataGridView cells based on actions of the user. For more information about implementing virtual mode, see How to: Implement Virtual Mode in the Windows Forms DataGridView Control. Please refer to the article How to: Implement Virtual Mode in the Windows Forms DataGridView Control for an example of VirtualMode.

By the way, this issue is related to Winforms. Please post this kind of questions to the Windows Forms Data Controls and Databinding forum in future.

Regards,
Jialiang Ge

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.