<howardw39> wrote in message news:13664@forums.infragistics.com...I put together a grid using Outlook style grouping, with about 30 choosable columns. About a third of the columns have custom summaries, and about half of these use custom Formulas in conjunction with an UltraCalcManager. It works OK except for one problem. When I change the grouping, or the sort order of a group, the change may take a second or so (there are 6,000 rows in the underlying table) before the grid appears to have updated. That is OK. But then the CPU keeps chugging away for another 5 to 15 seconds. Worse, with certain groupings, the CPU keeps going apparently indefinitely, as if it is in a loop. The UI continues to be responsive, so something is going on in a background thread. Does anyone recognize this issue or have advice on how to fix it?. http://forums.infragistics.com/forums/p/1887/13664.aspx#13664
Hi Howard,
Do you have the latest Hot Fix? There was a known issue with grouping and formulas that could sometimes cause a performance issue like this. I'm pretty sure it was fixed.
If the latest Hot Fix doesn't help, you should submit a small sample project demonstrating this behavior to Infragistics Developer Support.
Get Help
I submitted this two months ago and received the following reply. Since then, nothing.
I was able to reproduce the behavior of long calculation time of the summary formula at my end. I have logged this behavior with our developers in our tracking system, with an issue ID of BR30242. This development issue will be assigned to a developer to research for a fix, workaround, or other resolution. If some other resolution is reached, I will contact you with this information. Issue Description: "Long calculation time for the SummaryFormula in the UltraWinGrid in GroupBy mode".
Issue Description: "Long calculation time for the SummaryFormula in the UltraWinGrid in GroupBy mode".
Then I recommend contacting Infragistics Developer Support and following up with them on the status of the issue.
I sent this e-mail:
Light at the end of the tunnel ....?
Howard,
Your message has been forwarded to my attention.
Our developers are still working on development issue BR30242. From what I understand, the solution that our developers are considering involve changes to a number of things that interact with each other in a complicated fashion. It will likely take quite a bit more time for our developers to finish the task and resolve this performance problem.
To ensure that this issue maintains the appropriate visibility within Infragistics, I am escalating this issue.
As noted before, you will be automatically notified when a fix for this issue is ready for download. If we identify a workaround or other solution that doesn't require waiting for a hot fix release, a Developer Support Engineer will notify you, via the Support.Net@infragistics.com email address I've copied on this message.
Sincerely,
Vince McDonald
Manager of Developer Support, MCP
Infragistics, Inc.
Infragistics sent me a workaround:
1. Install the latest hot fix (2007 V3 or 2008 v1).
2. In the BeforeSortChange event, add the following: e.ProcessMode = ProcessMode.Synchronous;
This fixed the test app that I sent them, but our production App still would hang up calculating summaries when re-sorting. I found an additional workaround which, in combination with the above, eliminated this behavior:
3. In the BeforeSortChange event, remove the summarycolumns that are of type SummaryType.Formula, using code like the following:
index = Grid.DisplayLayout.Bands[0].Summaries.IndexOf("Target"); if (index >= 0) Grid.DisplayLayout.Bands[0].Summaries.RemoveAt(index);
Although we now seem to have a viable workaround, I'm still looking forward to receiving the full revision of the calculation engine. I think the recalculation times, although now acceptable for the point of view of users, are still too long. For example, with two group-by rows and 6,000 base rows, we should be able to do the recalculation in two passes thru the data x four partial summary calculations. Since this currently takes about 12 seconds on a 2 GHz processor, we are using (12 x 2,000,000,000) / (2 x 4 x 6000) = 500,000 CPU cycles for each partial calculation, which not reasonable. The engine must be re-calculating something over and over or doing some other unnecessary slow thing.