In the Office2019 theme, the RadGridView's ScrollBar elements should have transparent background by design. This is the track's background shown behind the thumb element that allows drag-to-scroll. Currently, the ScrollBars have a gray background.

To work this around, you can define an implicit Style in the App.xaml that targets the GridViewScrollViewer control. Then, set its Background property.

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="/Telerik.Windows.Themes.Office2019;component/Themes/System.Windows.xaml"/>
            <ResourceDictionary Source="/Telerik.Windows.Themes.Office2019;component/Themes/Telerik.Windows.Controls.xaml"/>
            <ResourceDictionary Source="/Telerik.Windows.Themes.Office2019;component/Themes/Telerik.Windows.Controls.Input.xaml"/>
            <ResourceDictionary Source="/Telerik.Windows.Themes.Office2019;component/Themes/Telerik.Windows.Controls.GridView.xaml"/>
        </ResourceDictionary.MergedDictionaries>
        <Style TargetType="telerik:GridViewScrollViewer" BasedOn="{StaticResource GridViewScrollViewerStyle}">
            <Setter Property="Background" Value="Transparent"/>
        </Style>
    </ResourceDictionary>
</Application.Resources>

Dear Telerik Support Team,

I am encountering an issue with the RadGridView control in my application, which is impacting the usability for users relying on screen readers. Below, I have outlined the details of my development environment, the problem, and attached a sample project demonstrating the issue.

Issue Description:
In the attached sample project, I have implemented a simple RadGridView without any custom styling and populated it with sample data. I have observed that the focus behavior is inconsistent, particularly with the first cell in the RadGridView. When attempting to focus the first cell, only the cell itself receives focus, unlike subsequent cells where both the cell and the entire row are focused. This inconsistency results in screen readers failing to read out the content of the first cell, while they correctly read the contents of all other cells.

Upon further investigation using the Snoop utility to explore the visual tree, I noticed that the GotFocused event for the initially focused cell identifies it as being of type RadGridView, whereas, for other cells, the type is GridViewCell. This discrepancy seems to be at the root of the issue.

Attachments:
I have included a simplified, runnable standalone application that reproduces this behavior. Please find the sample project attached to this ticket.

I believe this might be a bug affecting the accessibility of the application, and I would greatly appreciate your guidance on whether this is a known issue with a workaround or if there's a fix available.

Thank you for your assistance.

Best regards,

Christian

First Tab:

Second Tab:

The first two pinned rows are scrolled outside of the viewport when you scroll. For example, if you pin 4 rows, the first two will be scrolled and you will see only the second two pinned. This reproduces in the Green, Windows 11, Crystal and Office2019 themes.

To work this around, set the UseLayoutRounding property of RadGridView to "False". Or use a different Telerik theme.

The rows are measured and arranged wrongly when the ItemsSource is assigned to VirtualQueryableCollectionView. To reproduce this, one of the rows should measure with different height than the others. Also, this is reproducible only when the GroupRenderMode is set to Flat.

To work this around, set the GroupRenderMode property of RadGridView to Nested or avoid using VirtualQueryableCollectionView.

Reset by Clear, RemoveRange causes a memory leak of GridViewRow instances (or TreeListViewRow in RadTreeListView).
To work this around, you can call the Clear method of the RadGridView's Items collection and then reset the ItemsSource property.

this.radGridView.Items.Clear();
this.radGridView.ItemsSource = null;
this.radGridView.ItemsSource = newSource;
Edit: The number of instances of the GridViewRow class are relative to the number of containers which cover the visible viewport. They are kep by internal caching mechanism used for faster reuse of containers is data-reload scenarios. Containers are dettached from their previous viewmodels (DataContext).

In non virtualized scenario, the number of the live containers is the same as the number of items in the GridView's ItemsSource and when changing the source, the number remains the same as the items in the source.

We are closing this issue as we think the mentioned internal cache shouldn't be considered a memory problem but rather a powerful performance optimization internal tool for extensive data-refresh scenarios.

This happens in the following scenarios:

1. The FilterMemberPath points to the Date property of a DateTime one.
2. The column name contains "[]" square brackets.