Btw, can you comment on the release date for all these (wonderful ) fixes?

That's great, thanks very much (out of convenience, was posting as another user (mattwaldron -- was cached in IE) -- got off my tuckus a minute ago and registered).

Thx again... D

Matt,

The reason that the property wasn't in the docs is because it was something that was added after the initial release of 7.1.

One of the problems that we had encountered with the initial release was that scrolling perfomance was not good in many scenarios (e.g. when there was a significant number of cells per record). This was caused by the amount of time it took to hydrate new elements that would make up the visual tree for each new cell and record as they were scrolled into view, and then these elements were discarded as old records were scrolled out of view.

Therefore, in the last major hotfix we added the concept of element recycling, which is turned on by default. This dramatically improved scrolling performance since we were reusing existing element trees, and just changing their DataContext (i.e the DataContext of a RecordPresenter is its associated Record object).

The problem that you encountered, that we have since fixed, was that we weren't synching up the IsAlternate property on the RecordPresenter when its DataContext changed. By turning off element recycling for records you eliminate the problem.

We did have the foresight to add 2 properties to control this behavior RecordContainerGenerationMode and CellContainerGenerationMode. Here is what the enumeration values mean:

• Recycle - this is the default for both the record and cell modes. Note: we only recycle/reuse elements between contexts that are compatible, e.g, records have to be associated with the same FieldLayout and cells have to have the same data type/editor to qualify for reuse between them. This is also the only mode where the DataContext of the elements will change.
• Virtualize - this is only available for records. It is basically what happened all the time before. New element trees are hydrated as records are scrolled into view and discarded after they are scrolled out of view. Note: there is some caching going on so we don't get rid on things immediately.
• LazyLoad - we hydrate element trees as they are scrolled into view and never discard them. This improves scrolling back over elements that were already seen before. However, the downside is that if there are large numbers of records/cells that have been scrolled into view the memory footprint can grow. This mode is usually more appropriate with moderately sized data.
• PreLoad - we hydrate all elements up front and never discard them. Like LazyLoad this is appropriate only for smaller amounts of records/cells. The performance hit is taken at load time but the scrolling performance after that is optimal.

I hope this helps.

We are having similar issues with rendering (alternate styled rows not showing right, etc.) that seem to get solved by changing the RecordContainerGenerationMode, but I can't find this property in the online docs.  Can you explain the modes?

Thx

Do you notice any binding errors in the output window? 

One thing you might want to try is to change the bindings slightly in the CellValuePresenter styles to take advantage of the fact that the DataContext of the CVP is set to the DataRecord. e.g.

instead of

            <Image Source="{Binding RelativeSource={RelativeSource TemplatedParent}, Path=Record.DataItem.EditStatus,Converter={StaticResource Control_EditStatusToImageConverter}}"

try this:

            <Image Source="{Binding Path=(DataItem).EditStatus, Converter={StaticResource Control_EditStatusToImageConverter}}"