Hi,
I have a dataset that can have 10+ datatables with data relations between all of them (table 1 which is a parent to table 2 which is a parent to table 3, etc). I bind it to a wingrid and am able to navigate it by expanding it level by level etc, just fine. For the most part, I can modify fields in rows in the grid without problem as well. However, there is a very peculiar case where if I modify a field in the first child row of a particular parent row, and there are at least 8 levels below it, then CPU utilization goes to 100% for a long time. The more levels below, the longer it takes to where it will never complete. The activity appears to be in the datasource, i.e. doing a Break All and looking at the stack trace, it is in the area of System.Data.DataView, System.Windows.Forms.RelatedCurrencyManager.ParentManager_CurrentItemChanged etc, but not in anything Infragistics.
Thanks,
Bill
Hi Bill,
I doubt this is specifically a grid issue. The BindingManager in DotNet isn't very efficient, especially with very deep hierarchies like this. Personally, I recommend keeping the depth of your grid to between 5 and 8 maximum. Anything more than that and the BindingManager will start to choke.
Realistically, no human user can deal with 10 levels of data hierarchy, anyway.
You could try wrapping your data source in a BindingSource, if you are not already doing so. Sometimes that helps, but not always.
You could also try setting the SyncWithCurrencyManager property on the grid to false. That way the grid doesn't synchronize the active row with the position of the BindingManager, which can be a very expensive operation in a deep hierarchy. This assumes that you are not binding other controls to the same datasource and need to keep them in synch with the grid.
Hi Mike,
Thanks for the reply. This app is a manufacturing "product structure maintenance" app. E.g. a laptop computer is composed of a case, LCD screen, disk drive etc, and each of those subassemblies is composed of components and so forth. Our customer is a manufacturer who is very vertically integrated and their product structures can get up to 24 levels deep.
Agreed that humans can't deal with info past 10 levels. But convincing this customer otherwise is a tough sell.
I tried using BindingSource and that fixed the field modification problem. However a side effect appeared: binding to the control took exceedingly long, and for products with more than about 16 levels it would not complete in a reasonable amount of time.
At this point I am thinking about doing binding at a lower level (e.g. creating Wingrid rows programmatically instead of via databinding then binding the Wingrid row cells directly to fields in datarows via container objects, or similar). It's extra effort but I think I can get it to work.
Also, SyncWithCurrencyManager was disabled originally.
Regards,
I sympathize, but the reality is that the BindingManager in DotNet just isn't capable of handling that kind of depth in hierarchical data - at least not all at once.
It's possible that you could make it work by using the UltraDataSource and loading the data on-demand. But I expect that since the grid will still be creating the BindingManager, it might still be an issue.
wugates said:At this point I am thinking about doing binding at a lower level (e.g. creating Wingrid rows programmatically instead of via databinding then binding the Wingrid row cells directly to fields in datarows via container objects, or similar).
I'm not entirely sure what you mean by this. There is no such thing as an unbound row in the WinGrid. And again, I don't think it's the actual data rows that are the problem. Simply having a hierarchy that deep is most likely the root of the issue.If you want to test this out, I recommend creating an UltraDataSource and populating it with your entire set of data (with all 25 levels) and then bind that to the grid Test out the performance, make sure you can load the grid quickly and that you can drill all the way down to the bottom and edit cells and select rows. If that works, then using the UltraDataSource might be a viable solution.
If your application does not require summaries, filtering, printing, or exporting the grid, then using the UltraTree instead of the UltraGrid might be a potential solution. The tree tends to be a little more efficient than the grid and only creates the BindingManagers on-demand. But even this might not work once the user actually drills down past 8 or 9 levels of data.
Sorry for the late reply. I did a proof of concept test using an UltraDataSource and this did not have the same problem. So I am going to pursue this as a solution. The on demand capability of UDS makes a lot of sense as well. This will permit the user to drill into a product structure tree node-by-node and avoid having to "explode" the entire tree in advance as is done currently.
Okay, just make sure your testing includes drilling down way down deep into the hierarchy and then make sure the performance is still good with things like selecting or navigating rows at both the lower level and the root level. :)
Apologies for yet another delayed response. I tried drilling down but after expanding into about the 10th level, performance deteriorated exponentially with each successive level to the point where CPU usage was saturated for an indefinite amount of time, and I had to kill the process.
With all the issues associated with databinding I have decided to not use databinding and instead programmatically manipulate the wintree's node tree. So far so good, as I've been able to drill into a 24-level product structure tree and modify any node and have not encountered any performance issues. The downside of course is not being able to use "the magic of databinding". In other words I have to write my own plumbing.
Yeah, that's not surprising. It's an exponential increase as you go down.I've never been able to get decent performance beyond level 8. Normally, that's okay, because no human user could possibly deal with such a complex hierarchy, anyway - at least not without a lot of help.
I think manually populating the tree is the wisest move and will save you some headaches in the long run, even if it requires a bit more coding up front.