Warning: wall of text to follow....
I've read through the performance section of the help for the RadGridView and see where it says not to add a RadGridView as a child to something like a StackPanel or anything else where the children could grow to infinity because it will turn virtualization off for the grid. It further states that you should only add the grid to a container with a limited number of children.
That's a fairly huge design restriction, in my opinion. For example, I want to place a grid within a dockable/pinnable/unpinnable pane and include a RadExpander above it to allow the user to modify some options for that grid. The only way I can see of successfully getting everything to size/resize appropriately when the expander is expanded/collasped is to place it in a StackPanel with the Grid. However, doing so kills the perfomance.
So, I've had to resort to placing the options for the grid and the grid itself within two separate tabs in a RadTabControl. This, to me, is simply going to be confusing and combuersome for most of my users as the user will only be able to see either the options for the grid or the grid itself, not both.
I can't even force the grid to use virtualization nor can I get it to load its data asynchronously using the DataLoadMode property.... As a result, I feel I am being forced into providing a poor UI design for my users because the RadGridView's performance seems to drop off exponentially with the number of rows...
I just can't fathom why it's not possible to specify HorizontalAlignment="Stretch" and VerticalAlignment="Stretch" to give you the same "bounds" for the grid you would have otherwise within a container control that allows only one child to preserve the virtualization capabilities. That, or why it's not possible to improve the performance of the non-virtualized grid so it doesn't "hang" an application with a few thousand or more rows....
I've read through the performance section of the help for the RadGridView and see where it says not to add a RadGridView as a child to something like a StackPanel or anything else where the children could grow to infinity because it will turn virtualization off for the grid. It further states that you should only add the grid to a container with a limited number of children.
That's a fairly huge design restriction, in my opinion. For example, I want to place a grid within a dockable/pinnable/unpinnable pane and include a RadExpander above it to allow the user to modify some options for that grid. The only way I can see of successfully getting everything to size/resize appropriately when the expander is expanded/collasped is to place it in a StackPanel with the Grid. However, doing so kills the perfomance.
So, I've had to resort to placing the options for the grid and the grid itself within two separate tabs in a RadTabControl. This, to me, is simply going to be confusing and combuersome for most of my users as the user will only be able to see either the options for the grid or the grid itself, not both.
I can't even force the grid to use virtualization nor can I get it to load its data asynchronously using the DataLoadMode property.... As a result, I feel I am being forced into providing a poor UI design for my users because the RadGridView's performance seems to drop off exponentially with the number of rows...
I just can't fathom why it's not possible to specify HorizontalAlignment="Stretch" and VerticalAlignment="Stretch" to give you the same "bounds" for the grid you would have otherwise within a container control that allows only one child to preserve the virtualization capabilities. That, or why it's not possible to improve the performance of the non-virtualized grid so it doesn't "hang" an application with a few thousand or more rows....
1 Answer, 1 is accepted
0
Hello,
Vlad
the Telerik team
This is how the platform (both WPF, Silverlight and now Windows 8 XAML) works. If you have UI virtual component measured with infinity, the component will attempt to create all UI containers for all data items at once. You can check MSDN for more info.
Regards,Vlad
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.