Background
I am using the UltraDataSource to bind to an UltraGrid in LoadOnDemand mode. The ultradatasource receives updates after it is bound to the grid and the first update is very large so I lock on an object and process the updates.
The hierachy of the data being processed is such that there are up to 15 top level Rows all with their own Bands - which are childbands of UltraDataSource's Band property.
These top level rows have at least one child row each and in some cases these child rows have child rows themselves - which have a different Band.
I add the top level bands at start up - because i know the columns - but there are no rows. When the rows arrive in this initial update i have to add the grand child's band to the row. I do that with this code:
Rows[ParentRowIndex].GetChildRows(ParentRowBandName)[ParentRowIndex].Band.ChildBands.Add("ChildBandName")
The above is an abridged version of my code which has checks for nulls etc.
Once the child band is added i add the child band's columns.
My 2 questions
1. When i add the childband columns i notice the UltraGrid's RowInitializeRow event gets fired, but the data has not been set yet in the datasource. Is there a way i can prevent the row init from firing until the update has finished processing?
2. When adding the columns to the child band the grid loading (which has a lock so get cell data requested handler is blocked until this is complete) takes a lot longer than if columns are added to the bands before binding to the grid.
I know the above because i moved the top level bands's column adding to initialisation of the ultradatasource before binding and it sped it up, problem is i dont know which child rows have grandchildren so i have to add the columns when those grand child rows arrive in an update. i know the above has been covered in other threads - suggestions such as begin / end update and row synching but that has not made much of a difference. Any other ideas are definitely weclome.
FYI - during testing the first update has 15 top level rows each with 36 child rows and then about 10 of those child rows have grand child rows. The top level band has one column, the child band has 71 columns and the grandchild's band has 16 columns.
grasshopper said:Very interesting that both of you got the sample project to work on 10.1
This is really not all that surprising. One of the hallmarks of threading issues is that they are inconsistent. My guess is that we would eventually experience an exception in some completely unrelated and baffling place in the code that has nothing specifically to do with threading. These kinds of errors often occur when the grid tries to paint itself and finds that something has gotten out of synch, but there's no indication why.
Very interesting that both of you got the sample project to work on 10.1 but as you state and your attached thread reiterates, the Binding Manager is not threadsafe. As such i will persevere on the UI thread.
Thanks for your help Dave and Mike.
Hi,
I tried your sample with NetAdvantage 10.1 (latest SR) and I did not get an exception, either. But I can tell you with certainty that what you are doing here is not going to work. I'm not at all surprised that you are getting exceptions with this code.
Neither the WinGrid, nor the DataSet class, nor the BindingManager in DotNet are thread-safe. So binding a control to a DataSet and then modifying that DataSet on a separate thread is almost certain to cause a race condition and there is no way you can effectively handle that because you are not in control of the communication between any of those objects.
There is a long, detailed discussion about this here:
Work with a dataset bound to a grid on a separate thread - Infragistics Community
Without changing anything (no uncommenting of marshalling code to the UI thread) you just run it and you should get an exception.
Couple of questions:
1. What version of Infragistics did you use?
2. Did you leave the line "ultraGrid1.Invoke((Action)delegate {" in of "PopulateDataSource" in Form1 commented out so the update is performed on the Background thread rather than being marshalled to the UI thread?
Hello,
I ran your sample and it seemed to run fine. Could you tell me exactly what I need to do to reproduce the issue?