Create content control and change the content in it -when the content contains RadDock the WPF window lose focus.

The XAML team has recently reviewed this issue and will not be addressing it as at this time the team is focusing on the bugs impacting the highest number of developers. If you have encountered this issue and it is blocking for your work please contact us through the support ticketing system with details on your setup and a reference to this item.

When a pane is unpinned, mouse over it in order to show. After that when the mouse is removed from the pane it flickers before the animation is started.

Removing the Right mouse button ContextMenu of ToolWindow is not possible.

If the IsHidden property of a Pane placed inside the Document host is bound to a property in the ViewModel with value of True the IsHidden property at start-up is reset to False.

Using the LayoutChangeEnded event to save the layout when docking a floating Pane causes that Pane to not be saved correctly.

With code below the radPane will remain hidden (radPane is floating pane):radPane.IsHidden = true;

radPane.IsHidden = false;

Available in LIB version 2016.2.530, it will be also available in the 2016 R2 SP1.

I have a scenario where I only want to unhide the pane when certain property of the document is true.

For example: I have 3 panes A,B and C

Panes A and C are visible.

Active Pane should always be Pane A.

By default pane (B) is hidden.

Now when I set the IsHidden Property of the pane B to FALSE. Pane B now becomes the active pane.

I still want Pane A to be the Active Pane, but show the Pane B in background.

If I try setting the Pane A to be the active pane after Pane B is shown. It flickers which you can see here http://screencast.com/t/dGvU7UwUyYp

Is there any way i can unhide the pane in background while the active pane remains the same without having this flickering scenario.

Available in LIB version 2015.2.817, it will be also available in the 2015 Q3 Release.

This leads to loading wrong Template whenever the layout is loaded.

Available in LIB version 2016.2.530, it will be also available in the 2016 R2 SP1.

It would be great to be able to use other Resources other that the App.xaml for the Styles applied to the ToolWindow instances.

As they are automatically created and as expected are in a different visual tree accessing for example the Resources of the MainWindow is not possible.

Available in the 2016 Q1 SP1 Release.

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.

Available in LIB version 2017.3.1225, it will be also available in the R1 2018 Release.

A possible workaround has been demonstrated in the attached project.

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}

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.