Approved
Last Updated: 06 Dec 2019 15:18 by ADMIN
ToolWindow does not respect the "Show window contents while dragging" setting when it is first floated.
Approved
Last Updated: 03 Dec 2019 14:47 by ADMIN
Prevent the closing of the auto-hide area if the context menu of an element in it is opened.
Approved
Last Updated: 28 Oct 2019 16:31 by ADMIN
Approved
Last Updated: 01 Nov 2019 09:21 by ADMIN

This feature request is related to Ticket 1435779

 

Image for context

 

Currently, there's no support for increasing the drag threshold for the items on the orange box. Even after setting the values below.

DragDropManager.MinimumHorizontalDragDistance = 5000;
DragDropManager.MinimumVerticalDragDistance = 5000;

 

It would also be beneficial if instead of just relying on the drag threshold which is the box. Add a support for a sort of "Drag Time" concept where we can define how long the user should've held the actual pane before dragging/going outside the threshold.

Approved
Last Updated: 07 Jun 2019 10:52 by ADMIN

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}
Approved
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.
Approved
Last Updated: 07 Feb 2019 15:40 by ADMIN
Created by: Martin Ivanov
Comments: 0
Category: Docking
Type: Bug Report
1
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;
    InitializeComponent();
}

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
Approved
Last Updated: 28 Dec 2018 08:39 by ADMIN
The RadDocking control template hosts several AutoHideArea elements, one for each auto-hide placement - left, top, right, bottom. When you unpin a RadPane, it goes into one of those areas. The active auto-hide area where the pane will go is determined by the State of the topmost RadSplitContainer.

Allow manually setting the auto-hide area where the RadPane will go when unpinned.
Approved
Last Updated: 21 Nov 2018 16:55 by ADMIN
The RadPaneGroup inherits RadTabControl and the TabStripPlacement property. Currently the RadPaneGroup does not support setting this property as the corresponding ControlTemplates are not implemented.
Approved
Last Updated: 18 Sep 2018 09:38 by ADMIN
A possible workaround has been demonstrated in the attached project.
Approved
Last Updated: 19 Apr 2018 10:15 by Vladimir
Approved
Last Updated: 22 Mar 2018 13:05 by ADMIN
Approved
Last Updated: 15 Mar 2019 17:39 by ADMIN
Approved
Last Updated: 10 Nov 2017 18:04 by ADMIN
Approved
Last Updated: 30 Oct 2017 15:02 by ADMIN
Approved
Last Updated: 03 Jan 2017 21:16 by ADMIN
ADMIN
Created by: Georgi
Comments: 0
Category: Docking
Type: Feature Request
0

			
Approved
Last Updated: 03 Jan 2017 21:09 by ADMIN
ADMIN
Created by: Georgi
Comments: 0
Category: Docking
Type: Feature Request
0
    After starting the application, there are 2+ RadPane instances
    Each RadPane contains multiple TextBox controls
    Click on a TextBox in first RadPane
    Switch to the next RadPane
    go back to the first RadPane

The desired behavior is that the focus is restored to the focused element in step 3. Currently no element is focused. The same scenario in RadTabControl is a bit different and the TabControl focused the first element in its TabItem content.
Approved
Last Updated: 25 Aug 2016 12:58 by ADMIN
ADMIN
Created by: Geri
Comments: 0
Category: Docking
Type: Bug Report
0
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.
1 2 3 4 5