Currently, RadGridView's data engine relies on TypeDescriptor.GetProperties, when resolving the set of properties accessible through a certain type. Apparently, this API hides the properteis from the interface, as they are not accessible throught the concrete type.

The unconfirmed inputs of filter row editors are being destroyed together with the editor itself in column-visualized GridViews. There's an easy solution for it (store what was in there and restore upon recreation) and we're waiting for an official fix for this "expected behaviour" since three+ years.

Available in LIB version 2018.1.205, it will be also available in the R1 2018 SP2 Release.

As of R1 2018 the GetCellContent method is no longer used for exporting a custom column content. Instead, the GetExportCellContent one of GridViewBoundColumnBase needs to be overriden.

Similar to the one in RadPivotGrid:
https://docs.telerik.com/devtools/wpf/controls/radpivotgrid/features/localdatasourceprovider/serialization

And here is an online demo:
https://demos.telerik.com/silverlight/#PivotGrid/Serialization

I have a RadGridView and bind its ItemsSource and its SelectedItem to properties of the ViewModel (DataContext). I use a ViewModel for the grid items with overridden Equals and GetHashCode. When the ViewModel is created, the property bound to ItemsSource is filled and the property bound to SelectedItem is set to an item that is equal to one of the items in the collection (but not reference equal).

Problem:
When the GridView is displayed, no item is selected.

Note: I already reported this issue before: https://feedback.telerik.com/Project/143/Feedback/Details/227302-binding-itemssource-and-selecteditem-of-gridview-changes-selecteditem
but now I have managed to modify the sample project so that the problem can be reproduced. The difference to the original sample project is that Equals and GetHashCode of the Club ViewModel are overridden and the selected item is not reference equal to the item in the collection.

When RadGridView is bound to a ListCollectionView and the SortDescriptions are set, columns with a SortMemberPath different from the DataMemberBinding don't display the sort indicator in the column header.

In the attached example the "Status" and "ETA" columns are sorted. "Status" header does not display the indicator due to the SortMemberPath being different from the DataMemberBinding.

Available in LIB version 2017.3.1127, it will be also available in the R1 2018 Release.

Available in LIB version 2017.3.1204, it will be also available in the R1 2018 Release.

The reason for declining the item is that a possible fix for this behavior would practically interfere with the virtualization mechanism of the control. Shortly said, when the columns have their width initially set, RadGridView is aware of the column with the biggest size and performs its calculations based on it. When their size is changed on loading, the control cannot be aware of the size of a column that is not present in the viewport thus, the reported issue is observed. In order this behavior to be modified so, the engine needs to measure an element that is not yet loaded. We cannot commit ourselves to implementing this, as this would affect the virtualization of RadGridView. A possible workaround would be to avoid setting the Width of the columns initially in XAML.

When applying VQCV with custom IEnumerable as a source to the ItemsSource of the grid and filters grid through filtering control, ExportToXlsx exports wrong items.

Available in LIB version 2017.3.1127, it will be also available in the R1 2018 Release.

Available in LIB version 2017.3.1127, it will be also available in the R1 2018 Release.

The expanded state of the hierarchical item is not preserved when searching thought search panel for something that is not found and clearing search text.

Available in LIB version 2017.3.1113, it will be also available in the R1 2018 Release.

When setting the VirtualItemCount on refreshing the data source, the scrollbar jumps to the top. If the VirtualItemCount is initially set, the behavior is not reproduced. The workaround is to use the scrolling mechanism of the control and scroll back to the desired item.

Currently, the default value of the property is true, so the presented of items in the hierarchy collection is not taken into account. This results in having visible hierarchy buttons for rows that do not have hierarchical subitems.