Hi. I have a grid (v10.3) with around 9K rows, 30 columns, formulas, etc... The grid is loaded asynchronously from a datasource. When users turn on grouping (OutlookGroupBy), it takes almost a minute for the main thread to become live again, where user can drag a column to the grouping area. It appears the grid is asynchronouly firing the AfterCellUpdate event for every non-visible row in the grid. I am afraid of suspending events since aggregate calculations could be incorrect.
Question: How can I know when the grid or CalcManager is done with all async events? In other words, I need a mechanism to at least display an hourglass icon to the user so they don't think the application has crashed.
Thanks in advance,
-Mike
Hi Mike,
I'm a little confused. What do you mean exactly when you say the grid is loaded asynchronously? Are you using threading? Or are you using an UltraDataSource to load the data on-demand? Or something else?
It sounds like you are loading the grid on-demand. In a case like that, grouping requires the grid to load all of the rows into memory. It has to do that in order to sort and group the data. The same is true for filtering or summaries. You might be able to alleviate the delay for sorting by using external sorting, but I think grouping will still require that all of the data be loaded.
Anyway, where you lost me is why AfterCellUpdate is firing. Why would AfterCellUpdate be fired when grouping the data? That doesn't make any sense.
To answer your question, try the BeforeSortChanged and AfterSortChanged events. These are the events that fire when you group. I'm not sure if the AfterSortChanged fires when the grouping is complete, though. The grouping process probably doesn't occur until the grid paints. So if you find that AfterSortChanged is firing too soon, try calling grid.Update to force the grid to paint and that should cause a synchronous delay in code execution so you will know when to set the cursor back to normal.
Hi Mike. Thanks for your response.
You are right, the grid is loaded on-demand via an custom datasource. Further investigation revealed that grouping itself is not the culprit. The issue is that after turning on the grouping, I setup about 20 summaries. SuspendCalc and then ResumeCalc are called around it, which is what causes the InitializeRow and AfterCellUpdate events to fire. I resolved the issue by making CalcManager synchronous before the call to ResumeCalc. This way it blocks until all events are done.
grdDataView.DisplayLayout.ViewStyleBand = ViewStyleBand.OutlookGroupBy
calcManager.SuspendCalc()
setup summaries here...
calcManager.CalcFrequency = UltraWinCalcManager.CalcFrequency.Synchronous
calcManager.ResumeCalc()
calcManager.CalcFrequency = UltraWinCalcManager.CalcFrequency.Asynchronous
Thanks for your help,