Ok I "think" I might be going crazy... I'm fairly sure that this was working before I upgrade my grids from 8.1 to 9.2, but I have a fairly complex grid and I'm not 100% sure when it broke.
I have a grid with two bands. In the 2nd band I have some custom summaries that change the color of the same column in band 1 (Parent Row/column).
For the longest time it seems that the "child" band summaries were calculated even though they were not "visible". So the parent cells were colored correctly. Now the parent cells do not get properly colored until AFTER the parent row is expanded. I have confirmed that the child subtotal is NOT getting calculated until the row expands.
So I guess my question is did something change where the summaries for child rows are NOT calculated until AFTER the row is expanded? And if so is there anyway to force the grid to calculate all of its sub-totals even if they are not currently expanded?
I'm I going crazy??? I know this worked....
Dan
Hi Dan,
To my knowledge, summary calculations were always deferred until the value of the summary is requested by something in the code. In other words, they are calculated lazily when something in the code requests the value, and that includes when they are displayed on the screen.
I suppose it's possible that this worked differently in a previous version of the grid, but if so, that was probably an anomaly.
Either way, I'm pretty sure there are things you can do in the code in order to force the summary to be calculated when you want it to. But how you do that depends on the type of summary you are using. Are you using the grid's build in summary types or are you using a formula?
I'm using a "Custom" summary class. And it is working the way I want it to.
If I put an expand all after I load the grid, the band 2 total get calc'd properly and the changes to my Band 1 cells are getting updated properly.
So is there a way to force the calculations without expand all? I tried an expandall followed by a colapse all, and it didn't do the trick. Is there something I can do to force the calculations? I tried doing a refresh on the band 2 summaries and that didn't seem to work.
Thoughts?
UPDATE!!!
Well I reread your initial response, and took into account your statement about it always being lazy. Then I realized that in your sample you WERE accessing the summary value in the init row.
So I setup a loop that goes thru and simply access the child band subtotals, and that did it. Works fine on a small grid, but slows things down a bunch on bigger grids. But I'm sure that I will figure out a way to get it more efficient!
So my problem is solved. Thanks for all of your help. Even though I have been programming these grids for something like 6 years now, every day I seem to find something new.
Thanks again!
Well the plot thickens...
Ok so the test project that you sent me, with my modification works as expected. When the grid is displayed the parent cell is colored red. However, AFTER fixing the problem in my InitRow method and REMOVING the try catch I'm still not working correctly.
My Custom Summary Class is not that much different than the sample. So I set a break point at the top of my End Summary Method, and it does NOT break until I expand the parent row. BUT when I set a break point on the "Row[0]" line in the sample project it DOES break before the grid displays.
This tells me that the Summary is NOT being calculated until the row is expanded in my grid.
In the sample you sent me, I did remove your references to the Infragistics DLL's and replaced them with pointers to the exact DLL's on my machine. So I would assume that I'm using the same version of the DLL in both my project and the sample project.
So I guess I'm wondering is there ANY setting on the grid that will delay the calculation of the summary's on a child band? I just wonder if maybe the default changed or something. There has to be something here. Yes I have a complicated grid, but like I have said, as soon as I expand the parent band it does run the custom summary. (If I do an expand all, it DOES color the cell correctly.)
Could there be something that delays the calculation if the number of rows or number of summaries exceed a certain amount. Heck in most cases I would argue that delaying the calculation of hidden subtotals would be the correct action to speed the display of the grid.
I sure do appreciate your continued response.
Thank you, Thank you, Thank you!
Your project was helpful! You are correct, with a slight modification I was able to prove that things are working correctly in the grid. To make your example match what I'm doing I had to change the Custom Summary class to the following:
object ICustomSummaryCalculator.EndCustomSummary(SummarySettings summarySettings, RowsCollection rows) { // return 5000; rows[0].ParentRow.Cells[1].Appearance.ForeColor = Color.Red; return 1; }
With this change my cell 1 in the parent row WAS changing to Red. So I have a problem in my grid. I have a feeling it just might be in my Init Row handler. I have a Try Catch and that might be causing my problem.
Thanks again for your help!
I tested this out and it seems to be working just fine for me. Simply accessing the Value on the summary is forcing it to be calculated. I tried this first with a Sum summary, and then with a Custom summary, just to make sure it wasn't something specific to the Custom type.
I'm attaching my sample here so you can see if the same code works for you. If it does not, then it must be a bug in the version you are using, in which case, you will need to get the latest service release.
If my sample works for you, then we need to figure out what's different in your real application.