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.

The compasses of the other ToolWindow appear.

    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.

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.

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.

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.

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).

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.

Just like in Visual Studio, a floating pane, which I want to dock (for example to the bottom), can either take the whole width or just the width that is left.

For example:
At start, the panes in the bottom does not consume the whole window width. After undocking the panes and docking them back, the compass only shows me an option to dock the panes while consuming the whole width.

I have no option to return to the original state (like in Start.png). The only way to return to that state is undock and re-dock the right pane, and then dock and re-dock the left pane.

Visual Studio has this feature (see image).

Currently when a Pane becomes floating and we are still holding it with the mouse the ToolWindow could not be snapped. First the mouse should be released and right after that the ToolWindow could be snapped.