In my form called "Tagout Maintenance" I have loaded multiple tables into a dataset. Table "tagdata" has about 8,000 rows. It is the parent table. The child table is "tagcomp" and the relation is:
Dim MyRelation As New DataRelation("TagdataToTagcomp", ds.Tables("Tagdata").Columns("reqno8"), ds.Tables("tagcomp").Columns("reqno12"))
Dim fkc2 As ForeignKeyConstraint = ds.Relations("TagdataToTagcomp").ChildKeyConstraint
fkc2.DeleteRule = Rule.Cascade
fkc2.UpdateRule = Rule.Cascade
fkc2.AcceptRejectRule = AcceptRejectRule.Cascade
There are two other relations, TagdataToGrptag, and TagdataToTagPermit.
I have a ultratabcontrol where one tab has a form that displays one Tagdata record (called the Standard View Tab) and all of its child records. The child tables are defined but initially empty and are loaded when their parent record is displayed in the "standard view" tab page.
The second tab (called the RowView Tab) has a form which contains a datagrid (dgTagoutRowView) which displays each of the 8,000 tagdata records one row per record. The datasource for the grid is:
dgTagoutRowView.DataSource = ds.Tables("tagdata").DefaultView
dgTagoutRowView.SyncWithCurrencyManager = True 'I tried false also but no difference
When the user switches to the "Row View" tab I basically do the following in the "selectedTabChanged" event:
ds.Tables("tagdata").DefaultView.Sort = "reqno8 desc"
If tabcontrolViewSelection.Tabs("Row View").Selected Then
dgTagoutRowView.ActiveRow = dgTagoutRowView.Rows(BindingContext(ds.Tables("tagdata").DefaultView).Position)
'In order to position the dgTagoutRowView to display the record currently displayed in the Standard View tab I do this:
'I then do some minor housekeeping and do an EXIT SUB.
The code seems to work fine, and if the number of TagData Records is 500 or so, the code is pretty fast (about 5 secs). However, when the customer tested with 8000 tagdata records the time took about 50 seconds or longer.
Stepping thru the code the 50 sec delay occurred at this line:
and there was no delay at the "end sub" line.
Next I commented out the above line and the ScrollRowIntoView line to see what would happen. I then got a delay of 40 secs when executing the "end sub" line. Apparently something is going on in the background before the screen appears and control is returned to the user.
Next I uncommented the "dgTagoutRowView.ActiveRow =" line and ran the program again. Again starting at the "standard view" tab (the default initial tab) and clicking the "row view" tab it took about 50 secs to complete.
Now here's the crazy part. After the delay and the screen comes up, I then clicked the "Standard View" tab and it came up immediately, and then I clicked the "row view" tab and it also came up immediately... no delay. I could change recs in the standard view, switch to row view, switch recs in row view then go back to standard view... all with immediate response, no delay at all. Something seems to be taking 50 secs to "initialize" the first time around, and then response is immediate. If I click my "refresh data" button which re-loads all the datasets with the current data from the database, the initial 50 sec delay returns when trying to go to "row view".
When first going into the Tagout Maintenance screen and switching to "row view" the cpu goes from 1% to 15% and stays there for the 50 secs of delay. The screen then displays the row view and cpu goes back down to 1%.
I've tried for days to try and figure out what the delay is but have not had any success. Based on what I've described do you have any suggestions as to what might be happening in terms of background processing for that 50 second delay where the cpu is at 15%?
I'm using Infragistics 15.1.20151.2132 and Visual Studio 2013
I tried a couple more things.
Dim RowviewBindingSource As New BindingSource(ds, "tagdataRV")
dgTagoutRowView.DataSource = RowviewBindingSource
no change. Delay still occurs.
After multiple hours of tearing the code apart, I found the issue. In my dgTagoutRowView_initializerow I was doing a "e.Row.PerformAutoSize()". THAT was what was taking so long. Commented it out and grid comes up immediately. Hopefully anybody else having issues with slow loading datagrids will see this post and check their initializerow routine.
Hm. That makes sense, I guess. That code will get hit once for every root-level row when the grid first displays, and it will force the grid to create ever row and cell object (which it does lazily).
If you are using the default setting for the RowSizing property, then all of the rows are the same height, anyway, so you only really need to autosize once, not once for each row. If you are using a RowSizing setting that allows for variable-height rows, then you can make things more efficient by only autosizing the rows in view. Maybe trap the AfterRowRegionScroll event of the grid and loop through the e.RowScrollRegion.VisibleRows collection and autosize each visibleRow.Row.
This was code I wrote in the very beginning, before I really knew the finer points of the toolset. Never noticed it before because none of my customers had that many records. Anyway, turns out I didn't even need to do it because I set the datagrid.displaylayout.override.RowSizing = AutoFree with a RowSizingAutoMaxLines = 5, which does just what I want without having to do the autosize, and there is no delay with processing the grid. So, literally, the datagrid display delay went from 50 secs to instantaneous.