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.

Depending on the chosen theme, the page TextBox will not display all of the digits. This is inconvenient in scenarios where the RadDataPager has many pages.

To work this around, subscribe to the Loaded event of RadDataPager and retrieve the ScrollContentPresenter element with x:Name="PART_ScrollContentPresenter" using the ChildrenOfType extension method and set its Width property to the desired value and HorizontalAlignment property to Center.

private void radDataPager_Loaded(object sender, RoutedEventArgs e)
{
    RadDataPager radDataPager = (RadDataPager)sender;

    ScrollContentPresenter scrollContentPresenter = radDataPager
        .ChildrenOfType<ScrollContentPresenter>().FirstOrDefault(x => x.Name == "PART_ScrollContentPresenter");

    if (scrollContentPresenter != null )
    {
        scrollContentPresenter.Width = 45;
        scrollContentPresenter.HorizontalAlignment = HorizontalAlignment.Center;
    }
}

As a <role> I want <ability> so that <benefit>.

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.

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.