Question DataGrid with many rows -> Application freezes

STiAT

New member
Joined
Aug 29, 2008
Messages
2
Programming Experience
10+
Hello,

First of all, let me state that this high numbers on entries in the datagrid is definitely necessary. At least that they get cached or similar. If you are interested why, I can clarify this in one of my next posts.

We've some datagrid view, usually holding from 500-15000 rows (10 columns), getting updated (with differences, where entries are created, updated or deleted) every 5-10 seconds (some "real time" application).

Now, receiving data by our unix box (TCP/IP protocol) is done in a own thread, so the UI won't block and so on. This works very well, but we seem to face a problem a little later.

When we are holding 15000 rows in the grid (colored and so on), and we're inserting rows (differences from the last fetch to the current fetch) into the DataGrid, the UI "freezes" for some seconds.

Basically, it seems as when .NET does any action on the DataGrid form (updating, sorting or similar), the whole application freezes for some seconds.

This does not make a nice appearance of the applikation to the users.

The question is:
Can i seperate the Forms in my Application to different threads, so that the drawing and updating is also done in this seperate thread? Everybody will understand that managing thousands of lines takes some seconds - so one control can freeze. But the rest of the application should stay responsive.

Currently, spawning several threads handling the Forms still had no effect. It seems as if the drawing is still done in the "main" application thread.

We do not use real "background workers" yet. We manually spawned the threads (since we guys are used to VB6 and C++).
Do background workers ensure, that the updating and drawing is also done in the worker? Or will this still have an impact on the main application thread?

On the other hand, can there be some "caching" implemented? We're holding the data in the background in special views in the memory, so we can basically easily update the grid when needed. I'm just a bit unsure about the sliders (setting to the correct height - telling the datagrid how many entries it would have).
It is not necessary that everything is always held by the grid - but it should be possible to scroll trough the datagrid easily, permanently showing entries while scrolling.

Kind regards
// STi
 
Last edited:
Hello.

When we are holding 15000 rows in the grid (colored and so on), and we're inserting rows (differences from the last fetch to the current fetch) into the DataGrid, the UI "freezes" for some seconds.

I can believe that, since he needs to 'push' thousands of entries along the array to insert the new one at this position.

I don't know if there's any way to get the drawing into another thread, but I don't think that VB would like that, since the control on which is drawn is in another thread. But, you could try to create the DataGridView on Runtime in another thread...I've never done such a thing and you may need to kick the thread-control (CheckForIllegalCrossThreadCalls or so) for that.

Good Luck,
Bobby
 
Hello.



I can believe that, since he needs to 'push' thousands of entries along the array to insert the new one at this position.

I don't know if there's any way to get the drawing into another thread, but I don't think that VB would like that, since the control on which is drawn is in another thread. But, you could try to create the DataGridView on Runtime in another thread...I've never done such a thing and you may need to kick the thread-control (CheckForIllegalCrossThreadCalls or so) for that.

We actually create DataGridViews, updating the form with a delegate.
Allthough, it's a quite obvious design flaw in .NET then, if it is not possible at all to thread display elements correctly.

I'll report back if I find any solution for this.

// STi
 
Why don't you databind the Datagridview to your collection, and just update the collection? Let winforms worry about refreshing the UI.
 
Back
Top