Last Updated: 11 Aug 2020 14:13 by ADMIN
The ToolWindows of the RadDocking control remain open even if the application is minimized when a remote connection is restored.
Last Updated: 16 Jul 2020 10:57 by ADMIN
When clicking a RadGridResizer element while a context menu is open, the RadSplitContainer is resized. 
Last Updated: 07 Jun 2019 10:52 by ADMIN


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}
Last Updated: 09 Apr 2019 07:07 by ADMIN
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.
Last Updated: 07 Feb 2019 15:40 by ADMIN
Created by: Martin Ivanov
Comments: 0
Category: Docking
Type: Bug Report
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.
public MainWindow()
    AutomationManager.AutomationMode = AutomationMode.Disabled;

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

Last Updated: 18 Sep 2018 09:38 by ADMIN
A possible workaround has been demonstrated in the attached project.
Last Updated: 30 Aug 2018 15:25 by ADMIN
Last Updated: 10 Nov 2017 18:04 by ADMIN
Last Updated: 30 Oct 2017 15:02 by ADMIN
Last Updated: 25 Aug 2016 12:58 by ADMIN
Created by: Geri
Comments: 0
Category: Docking
Type: Bug Report
Possible workaround:

A custom RadDocking control can be created, in which the OnCreateAutomationPeer() method is overridden. OnCreateAutomationPeer() should return a custom RadDocking AutomationPeer, in which the ToolWindowAutomationPeer is removed from the collection of child elements of RadDocking AutomationPeer.
Approach demonstrated in the attached project.
Last Updated: 03 Aug 2016 12:51 by BENN
When dragging a pane in Deferred DragDropMode, if the moue cursor is far from the header, then the Drag Cue appears far from the cursor.
Last Updated: 03 Aug 2016 12:52 by ADMIN
On some rare cases, RadPane.OnPaneLoaded is being called before ApplyTemplate was called, and therefore, UpdateAllowDrag which tries to find the first child of the rad pane (the "wrapper" grid) fails, and pane remains undraggable.

To reproduce this issue, I have a button that when clicking on it, it adds a new pane (There is a collection of View Models, that when items are added or removed, then a code that is using binding to that collection adds or removes a pane.

The scenario happens when the system is laggy (For example, heavy UI on the panes content), and I'm adding several view models to that collection.
It doesn't always happen, but sometimes, one of more of the panes are not draggable.
I can clearly see that the OnPaneLoaded was called before the OnApplyTemplate was.

Maybe it can be a good idea to call UpdateAllowDrag on the OnApplyTemplate function if the OnLoad was called first.

Last Updated: 03 Jan 2017 21:10 by BENN
On Deferred mode, you can still undock panes (for example, but context menu).
The problem starts when you want to dock them back, When moving a pane above the compass, it hides the compass (And this problem is a PITA when you docking with the inner compass (rather than the root compass), since the left,top, center etc.. arrows are near to each other (so you are not 100% sure you hit the right arrow).

Last Updated: 04 Aug 2016 10:49 by BENN
When changing the DragDropMode in runtime, the panes behave unexpectedly.

If changing from Immediate to Deferred:

* Docked panes are not movable (no compass and no deferred adorner is being shows)

* Floating panes that are being docked do have the compass and the deferred adorner, when you try to move them after they were docked. 


If you change is back from Deferred to Immediate:

* Panes that you could not move can be moved (and then become floating) again/

* The panes that did have  the compass and the deferred adorner, don't move when you try to drag them. However, when you release the mouse button, then the start moving with the mouse pointer... without any mouse button pressed.

I've debugged the controls using the source code, and I've concluded that.

RadPane.UdateAllowDrag() is being called on PaneLoaded, which happens when I drag a floating pane into the Docking area.

In this case, when the DragDropMode is set to Deferred, then AllowDrag is set to True (with the call of DragDropManager.SetAllowDrag)

This is why that pane does have the Deferred Drag Adorner (The Drag Cue), while other panes doesn't.


On the other hand, when I change the DragDropMode to be Immediate again, then that pane is left with AllowDrag set to true, and it is registered to the DragDropManager events, which causes the second problem.


In my opinion, the RadPane.UpdateAllowDrag() should be called also when the DragDropMode is changed.
Last Updated: 04 Jan 2017 08:25 by ADMIN
The the keyboard focus is also lost if you undock a RadPane from its docked state.
As a workaround you can persist the focus as shown in the RestoreFocusOnStateChanged SDK example, that can be found here:
Last Updated: 03 Aug 2016 12:50 by ADMIN
If an custom implementation is implemented that restores the IsActive property state if a RadPane during the control's LoadLayout functionality the "Active" visual state if that RadPane instance is not cleared if different RadPane is selected.

This issue could be observed in the VisualStudioDocking located in the XAML GitHub repository here: https://github.com/telerik/xaml-sdk/tree/master/Docking/VisualStudioDocking
Last Updated: 03 Aug 2016 12:52 by ADMIN
While the control's DragDropMode is set to Deferred and the RadPane instances contain content which is UI heavy, dragging those RadPane instances in order to reorder or re-dock them may experience performance issues leading to sluggishness of the drag and drop action.
Last Updated: 04 Jan 2017 07:14 by ADMIN
When the control contains RadPane instances which Content is provided by a MAF framework that content experiences flickers and disappearing when the RadPane is being floated, docked, pinned or unpinned.
Last Updated: 03 Jan 2017 20:54 by ADMIN
Resizing a RadPane's splitter while its Header's or Content's ContextMenu is opened leads to incorrect resize
1 2 3