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.
As a workaround in the CustomElementLoading event handler you can call the SetAffectedElement() with creating DependencyObject and then Cancel the event by setting the Cancel property.
private void RadDockingOnCustomElementLoading(object sender, LayoutSerializationCustomLoadingEventArgs e){ if (e.CustomElementTypeName == "MyRadPane") { e.SetAffectedElement(new DependencyObject()); e.Cancel = true; }}
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}
As a workaround, you can disable the animation of the ToolWindow:
<Style TargetType="telerik:ToolWindow">
<Setter Property="telerik:AnimationManager.IsAnimationEnabled" Value="False" />
</Style>
The above style need to be placed in the resources of the App.xaml in order to take effect on the ToolWindows, since they are displayed in a separated visual tree.
Hello Support,
we are using the RadDocking.LayoutChangeEnded event to store the docking layout (via RadDocking.SaveLayout) after the user has changed it.
When animations are enabled (default) everything works as expected and all groups, split containers, and panes are included when in the XML written by RadDocking.SaveLayout.
However, when disabling animations (either using AnimationManager.IsGlobalAnimationEnabled or custom styles for RadWindow and/or ToolWindow setting AnimationManager.IsAnimationEnabled to false) the RadDocking.LayoutChangeEnded event is raised too early.
The faulty behavior can be reproduced with the attached demo application as follows:
1. start the application (App.xaml includes a style for ToolWindow with animations disabled)
2. drag the pane "Solution Explorer" out of the application to create a new tool window
3. drag the "Solution Explorer" tool window onto the "Properties" pane's compass and drop it below "Properties", so that "Properties" and "Solution Explorer" are both pinned right in the application above each other
4. when inspecting the layout written to the "Output" pane you will find that the entry for the RadPane "Solution Explorer" is missing
Any additional change to the docking layout (like resizing a pane) will update the layout and show all panes again.
When enabling animations in the ToolWindow style the above steps will result in the complete layout being written to the "Output" pane.
Please let me know should you require further information for reproduction of this bug.
Best regards,
Oliver
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.
Having Problems with unreadable Tabs in RadPaneGroup: TabsSqueeze.png
I think I found a Solution with OverflowMode and ScrollViewer:
<telerik:RadPaneGroup x:Name="DocumentGroup" ScrollViewer.HorizontalScrollBarVisibility="Auto" OverflowMode="Scroll">
Problem:
After Loading Layout the OverflowMode is not respected anymore.
I found this ticket in Silverlight, what discribes the Problem and is approved: Docking: I would like OverflowMode to work for all RadPaneGroup in xaml/codebehind and this be persisted through SaveLayout/LoadLayout
And i found this documentation, which say, using OverflowMode can lead to unexpected behaviors:
https://docs.telerik.com/devtools/wpf/controls/raddocking/general-information/not-supported-properties
so i report this as a feature instead of a bug.
Please sea atteched an example project: TabWrapProblem.zip
Usage: Save and than Load the Layout -> Scrolling of tabs break
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
Dynamically adding RadPane to PaneGroup, the header of the pane does not appear on the second added pane.
To workaround this the OnApplyTemplate() method can be called after the RadPane is added to the RadPaneGroup.
After upgrading to Telerik WPF 2019.1.116 from 2018.3.1010 we receive a lot of:
System.ComponentModel.Win32Exception (0x80004005): Invalid window handle
MS.Win32.UnsafeNativeMethods.GetWindowText(HandleRef hWnd, StringBuilder lpString, Int32 nMaxCount)
Exceptions. It makes out application very slow.
In version 2018 everyting was OK. See attached scerenshots.
Allow manually setting the auto-hide area where the RadPane will go when unpinned.
A possible workaround has been demonstrated in the attached project.
The compass elements are not on the proper places when the docking is on the second monitor. To reproduce this the DPI of the monitors should be different for example 125% (main) and 150% (secondary). Also, to reproduce this you will need to enable the DPI awareness of the application by setting the dpiAware and dpiAwareness settings in the app.manifest file.