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.
Multiple operations applied on a big RadBitmap can cause OutOfMemoryException because of used and not disposed unmanaged resources in a WriteableBitmap object. Steps to reproduce: - Execute multiple times the Rotate tool Observe: The memory goes up and retains such. Expected: The unmanaged memory is cleared. Findings: the memory leak is related to the WPF class WriteableBitmap which is internally used by the RadBitmap. Attached is a sample project illustrating the problem using only WPF classes. Note: At this point, we are not aware of a possible fix.
The ZIndex property change is not detected by the VisualizationLayer at runtime.
Workaround: remove and then add back the item where the ZIndex is changed.
System.Windows.Data Error: 26 : ItemTemplate and ItemTemplateSelector are ignored for items already of the ItemsControl's container type RadBreadcrumbBarItem
public
MainWindow()
{
AutomationManager.AutomationMode = AutomationMode.Disabled;
InitializeComponent();
}
Hi,
I am currently having issues with RadGridView's group footer: I am trying to add a button to the footer template which is supposed to trigger a command which in turn needs some info on the group it was triggered from*.
Since (unlike the header) there does not seem to be any info on the group available directly within the GroupFooterTemplate, I am pulling the group info from the parent GridViewGroupFooterRow:
<telerik:GridViewDataColumn [...]>
<telerik:GridViewColumn.GroupFooterTemplate>
<DataTemplate>
<Button Command="{Binding DataContext.ShowFooterGroupCommand, RelativeSource={RelativeSource AncestorType=telerik:RadGridView}}"
CommandParameter="{Binding Group.Key, RelativeSource={RelativeSource AncestorType=telerik:GridViewGroupFooterRow}}" />
</DataTemplate>
</telerik:GridViewColumn.GroupFooterTemplate>
</telerik:GridViewDataColumn>
This is working great as long as the RadGridView does not use Row virtualization. However, when I turn on Row virtualization and scroll around for a bit, the value I get passed as the CommandParameter is more or less random and has nothing to do with the group my button is actually located in.
I attached a small example project (.Net 6 but our app uses 4.8 so I set that as the Framework below) for you to try it yourself. Just scroll around and click the buttons while watching the debug output window. You will see that the groups in the output window will not match the group where you actually clicked the button after some scrolling.
Even when virtualizing, the Group key returned when binding to GridViewGroupFooterRow.Group(.Key) should reliably return the key of the actual group my button is placed in. It would be even better if it was somehow possible to get the group directly, without having to resort to FindAncestor.
Regards
Simon Müller
Hofmann Fördertechnik GmbH
* Basically I am trying to give the user a possibility to add new items to the individual groups and I don't want to add the button to the group header since that makes it too easy to accidentally hit the header's RadToggleButton, collapsing the group.
The designer of VS crashes with a "Key cannot be null" when custom markup extension is used in Style Setter. This reproduces in the sample app attached in the blog (http://www.telerik.com/blogs/bring-office-2016-inspired-style-to-your-app-with-ui-for-wpf) on the TextBlock of the RabRadioButton HeadingStyle (snapshot attached) if you open MainWindow in Designer. Runtime everything works as expected.
Tested with 16.8.4 - works as expected. Updated to 16.9.0 to match the client's setup and managed to reproduce the issue. The issue is reproducible also with the 16.10.0 version of Visual Studio.
The check mark of the RadioButton is misaligned when DPI settings are set to a higher than the default value, e.g. 125%.
The problem can easily be reproduced using the Telerik UI for WPF Demo application: