Dear Telerik Development Team,
First of all, I want to thank you for your great work on the RadTileView control for WPF. I appreciate the effort and attention to detail that you have invested in this component.
In my projects, RadTileView has brought significant value thanks to its visual appearance, the smooth animation when maximizing or restoring tiles, and the ability to provide distinct content for minimized and maximized states. It truly enhances the user experience, and I find the dynamic layout engaging and modern.
However, I have faced some challenges related to tile reordering and positioning:
The drag & drop rearrangement mechanism sometimes behaves in unpredictable or unintuitive ways, especially when there are many tiles or when tiles have different sizes.
There is currently no straightforward way to specify the exact row and column position of each tile when dynamically adding them from code.
It would be extremely useful to have a way to control or "lock" a tile to a specific grid position, for example by exposing explicit row and column properties for each tile, or by allowing developers to define the exact layout coordinates when adding tiles dynamically. This feature would make it possible to programmatically manage tile placement in complex dashboards, rather than relying only on the automatic layout and drag & drop interactions.
Such functionality would be highly beneficial in many scenarios, especially for enterprise dashboards where the layout must follow strict business requirements and should not be left to chance or automatic algorithms.
Would it be possible to consider this kind of feature for a future release?
If there is a known workaround or recommended approach to achieve precise tile positioning with the current RadTileView, I would greatly appreciate your guidance.
Thank you again for your work and support.
Looking forward to your reply!
Best regards,
If a RadTileViewItem hosts several controls (e.g. Buttons, RadioButtons) users should be able to change the focused element using arrow keys.
Posibility to group the TileViewItems needed
Initial state of TileView: A B C D E F G G is moved between B and E (current result) A B C D G F E REQUESTED RESULT: A B C D G F E
TileView: Add different methods for arranging Tile items. Asked by a client. For example "ColumnsOnly" would only shuffle items down within the column being inserted into. However this would also mean that gaps would have to be allowed. E.g. A B C D E F G If G moved between B and E then A B C D G F E
Add GridSplitters between the columns and rows of the TileView so that rows and columns can be resized. GridSplitters should be available when the tiles are restored or Minimized/Maximized. In the latter case, only a vertical one should be available to resize the minimized tiles' width in respect to the maximized one.
Provide support for changing the ItemContainerStyleSelector runtime.
ScrollViewer property needed like in RadTreeview
Add a build-in paging support for the RadTileView.
Implement a mouse wheel support for the Horizontal ScrollBars of the control
Add animations for items collection change (add/remove)
Add SingleNoToggle selection mode. In this mode the TileViewItem won't unselect on click.
Add support for IsSynchronizedWithCurrentItem
Allow setting minimum size of the rows and columns: I don't know at design time how many items there will be in the tileview, so if I set fixed height and width for items I can have the control using only 1/10 of the available space, but if I don't set them I can have many too-small items which content cannot be properly displayed. I need a minsize for the items so if I have few items they have a variable size and if they are a lot they use the scrollbars.
If minimized items are placed top, the horizontal scroll bar should be top as well and so on.
When an item is maximized, the other items should remain in restored state.
"Move the "Fluid" threshold properties to the TileView level. It seems rediculous that these need to be specified in every Item (sure, I know there is templating, but this would also reduce your code/logic for calculating the areas of items). If this can be done with attached properties it might be more intuitive and less obtrusive on the control (ex. <RadTileView RadFluidContentControl.LargeToNormalThreshold="200" />)."
Provide close functionality out-of-the-box.