Ok so when we set SummaryCellContainerGenerationMode to LazyLoad (because too many columns to do in preload), the problem is that the grid does not calculate how many summary definitions have been added per column, so it only shows the first row of the definitions, even if they have been added in the XAML.
This is definitely a bug in 12.2. Has it been resolved in a patch or new version?
Thanks,Doug
When the SummaryCellContainerGenerationMode is LazyLoad it is just creating the SummaryResultsPresenter for the fields in view (or CellPresenter in the case of showing labels with the cells) so that is all it can use for the measurement. The SummaryResultsPresenter by default contains an ItemsControl that happens to use a vertical stackpanel but that could be anything so it cannot assume (nor would it be accurate to) that the height it should use is a multiple of the height of an element even if it specifically knew the number of summaries in that cell and the max # of summaries in that same logical row so what you are describing is expected with that setting. The height of the summary row will increase as the taller SummaryResultsPresenter comes into view.
Ok I understand.
Is there a method I should call to force the summary virtualizer panel to refresh itself as I dynamically add new summaries to visible columns? I find that these do not display (as in they do not alter the summary height when I set their display area).
Also, from my testing when you add a group by field the summaries that are shown in the grouping area do not lazy load, they pre-load again causing a massive slow down.
I have a sample project that shows the issue Im having. How can I upload it to you?
Regards,Doug
When you reply to the post you can go to the options tab and add the attachment.
Sorry, should have checked the options tab.
The part about the height of the record not updating seems like a bug. I mean we're essentially treating the element as virtualized in which case we don't really consider the height of the element but in the case of the summaries we should probably consider the element we have there because we have no template element to fall back to. The part about summary cells within the group by not virtualizing I'm not sure. You could probably create a sample we can review it and write up an issue about it if needed. Perhaps we're considering the wrong fields when dealing with a summary - e.g. we're looking at the list of fields that are available for data virtualization.
HI Andrew,
Im not at my computer now but it is easy to replicate the group by issue. Just create a custom Summary Calculator and put a breakpoint on the begin calculation method and you will see that if you are not using a group by, only the visible fields are calculated. If you use a group by, all fields are calculated.
I was trying to do a solution myself to this by stopping the aggregate method if the field is not visible, but I havent yet managed to find a way to tell if a field is visible or not (as in within the scrollable viewing window) from the summary result/source field object (I posted another query about that). So if you are able to help with that query I may be able to do a workaround to the LazyLoad group by issue.