Currently, you can drag and drop panes only in their parent RadDocking control. Allow dragging from one RadDocking to another.

The DataContext of RadPane's content is lost when showing its preview in the DockingNavigator.

As a workaround, you could set the DataContext of the content element could be set explicitly.

Allow defining an additional "preview" tab that is shown at the right most part of the tabstrip area. This tab should have a special highlighting like faded tab header or a different background. This is similar to the Visual Studio preview tab that is displayed when you use the Go to Definition (F12) function on an API name. Usually you have a single preview tab.

Loading the layout does not set the size of the ToolWindow created for a floating-only pane.

Currently, the GridSplitter used for resizing an unpinned pane disappears after a certain threshold. We could include an option for it to not disappear.

The RadOutlookBar control takes a significant amount of time to load initially when it does not have a fixed width and its IsMinimized property is explicitly set to True.

A possible workaround, for the time being, is to set a fixed Width for the control and change its value in the Minimized and Restored events.

A memory leak related to the automation peers of the RadPane and RadPaneGroup appears when you close a pane (using its Close button) even if you call its RemoveFromParent() method.

To work this around disable the automation peers. To do so please set the static AutomationManager.AutomationMode property toAutomationMode.Disabled.

The issue originates from ItemsControlAutomationPeer. It is reported to Microsoft in their old connect portal here =>

https://connect.microsoft.com/VisualStudio/feedback/details/838165/memory-leak-in-the-itemscontrolautomationpeer-because-items-removed-from-the-itemscollection-are-still-strongly-held-by-the-weakrefelementproxystorage

Resizing a dynamically added group results in a change of other groups' sizes, if the original groups were previously resized as well.

When you handle the selection change by displaying a dialog window and bring the mouse back to the current RadPaneGroup, the newly-selected pane becomes floating.

This issue is replicable in a setup which has two monitors and wit different DPI.
If a docking window is resized to a width over both monitors, when the window is more than a half on the monitor with lower DPI, it is not possible to dock it.

Currently, the length between the pane groups and split containers is hardcoded. Add a property on the docking, the pane groups or the containers that will allow to determine the length of the resizer (the RadGridResizer).

We could improve the drag-drop functionality of the RadDocking control when the FlowDirection="RightToLeft".

The CaptionHeight property of ToolWindow determines the height of the area where you can start dragging the window, starting from the top edge of the window. Currently, ToolWindow is using a fixed height based on the default title's content. However, the Title and TitleTemplate properties allow you to introduce a title with bigger height. In this case, if the title height is bigger than the default CaptionHeight, you cannot start dragging if the mouse is under the CaptionHeight's position.

Adjust the CaptionHeight dynamically, according to the actual title content height.

The popup that becomes visible when hovering over a pinned pane is cut when ScaleTranform is set to the RadDocking control.

Description:

When using a display with scaling setting to more than 100%, floating pane docking does not work as intended. When dragging a pane out of a PaneGroup, and without releasing it, you drop it on top of another tab (so it is inserted into that position in the PaneGroup), nothing happens (window stays floating in that position). If you drag the already floating window on top of the same tab, then the default behavior happens and the pane is docked into the group. This behavior is reproducible on the Telerik UI for WPF Demo app.

See attached video for reproduction case in Demo app.

 

Technical Details:

For the failing scenario DragDelta on the ToolWindow is being triggered with wrongly scaled mouse position. On second drag drop operation, DragDelta receives properly scaled mouse position.

Failure case mouse positions:

DRAG START {864,128.8}
DRAG DELTA {871.2,142.4}
...
DRAG DELTA {864.8,114.4}
DRAG END {1081,143}

Second case mouse positions:

DRAG START {862.4,116}
DRAG DELTA {873.6,160.8}
...
DRAG DELTA {860.8,112}
DRAG END {860.8,112}

If the IsHidden property of a pane is set before the LoadLayout method is called and it also sets the IsHidden property of the pane, it is left in an invalid state  - with wrong visibility.

Currently, the RadPaneGroup has one Grid layout with Margin="5" present in its control template, which causes the Content of each child pane to be indented according to the Margin property's value.

To work this around, extract the control template, with x:Key="RadPaneGroupDocumentHostControlTemplate", and modify the Grid layout, which has its Margin property set to 5. After that, create a new style with TargetType="RadPaneGroup" and set its DocumentHostTemplate property, to the modified one.

When several unpinned panes are saved, each one of them is duplicated inside the generated XML. 

Add a visual element to display the exact drop location of an item, when reordering panes in a pane group.

Currently Minimize\Restore\Maximize buttons are not shown in the ToolWindow's header, so there are some inconveniences in use. For example, it's impossible to minimize tool windows easily.