Hi Jorvart, 

You should use the Records property off of the DataContext, which is an IList of your data objects that fall within in that grouping. Thus you don't need to identify the row. 

-SteveZ

Hi, 

A short follow-up on this task.

By using your example Stephen I was able to make GroupBy-rows that contain what I need. 

I made a DataTemplate that I attach to the grouped columns in the GroupeByCollectionChanged event, and then let a converter format the value the groupby rows displays (including custom generated sums).

This works very well when my report contains one grouped column only, but as I send the GroupByRow value to the converter:
{Binding Value, Converter={StaticResource groupFormatter}}
the bound value will not always be unique when more than one column are grouped.

The problem with this is naturally that when I am unable to identify the row, I am also unable find the child-rows that shall be used in my sum-calculations.

My question is therefore: Are there any way to inform the converter of which row in the report that the value comes from.?

Are there for example any other bindings than "Value" (and "Count") that can be used to identify the row?

Regards

Jorvart 

Thank you Stephen,

Good explanation, and  I see now why my attempt to solve the 'summary data only' task fails.

I think the link you provided will give me a better way of doing it and will try to implement this.

Regarding what feature I would like to see, I think it can be best explained as having the option of displaying values from the summary row in the group by row. The WPF grid has a way of solving this, but it would be very nice if these values, in the group by row, could also be presented in columns so that correponding values have the same position on the line.  

Regards Jorvart

Hi Jorvart, 

The xamGrid uses virtualization. So when you have a million rows, it only ever renders whats needed in the visible viewport. This rendering is done based on the size of the rows. So, say normally only 30 rows fit into the viewport. When one row goes out of view, its then recycled and used for a new row coming into view.

However, when you set the RowHeight to 0 for all rows, you're telling the xamGrid to then render one million rows. Which means all of those controls now exist in memory.

When you set the RowHeight to 1, you're going to render a lot of rows, but only the amount for the size of your ViewPort. So say your Viewport is 800 px tall. Then you're going to render 800 rows, which is a lot, but certainly not a million.

 Now in the beginning of this post, you said you were trying to replicate a feature in WPF. Were you referring to GroupBy Rows?  And from what i understand you're trying to display summary information in them? If thats the case, its actually a feature we are working on adding for a future release. So if you could give me more information on exactly what you'd like out of the feature that'd be awesome. 

However, in it's current state, you can perform the summaries on your own for the GroupBy row, it just won't be calculated for you: 

You'd need to use a ValueConverter in your Binding, and then you can use the information of the GroupByDataContext to walk through your data and calculate your Sums:

http://help.infragistics.com/NetAdvantage/Silverlight/2011/1/CLR4.0/?page=SL_xamGrid_Custom_GroupBy_Row_Display.html 

I hope this helps makes things more clear, 

-SteveZ

Thank you for your reply Stephen.

Your suggestions makes sense if i just wanted to hide all data or just a few rows, but I am afraid what I am trying to do is a bit beyond this. The sent code-snippet was a simplified version that I used while 'investigating' the problem.  

 In the WPF version of the grid the group rows as default generates "sum xxx=yyyy.yy" when a column in the report has sum activated.  I have not found any way to get this for Silverlight.

Then as an alternative I thought of giving the users the option of  hiding/showing the detail rows in such grouped reports. The summaries-row wil not be affected, so the effect will be to have only summaries or summaries and details.

 This looks nice for relatively small reports, but I see here also quite a big memory consumption.  I see that when I hide detail rows in this way, the memory consumption goes up, and is not released again when the details are again displayed. Continued showing and hiding with the same set of data does not increase memory consumption significantly more, and performes much quicker.

I will buy your explanation if you can explain to me why rendering every row with a rowheight of 0 makes the report consume so very much more memory than any other value...?

Example:  

I have a report that makes the iexplorer consume 114 MB  of memory when the data is loaded.

If i render the report with a rowheight of 20 the memory consumption increases to 125 MB and is rather stable around 120 MB when continuing to switch between 30 and 20 as row height.

But when I set the row height to 0, memory consumption increases to 595 MB, and stays around 620 MB when switcing between 30 and 0.

NB: I have tried the same with the new 11.1 version of the grid, but the problem remains.

Regards

Jorvart