Changing theme runtime when we have a floating RadPane, then dock it into one of the sides of an already docked RadPane and no splitter will show between them. Happens with implicit theming as well.
Possible work-around of this problem: private void RadDocking_ElementLoaded ( object sender, LayoutSerializationEventArgs e ) { if ( e.AffectedElement is RadPaneGroup ) { var PaneGroup = e.AffectedElement as RadPaneGroup; var Panes = PaneGroup.EnumeratePanes().ToList(); var SelectedIndex = PaneGroup.SelectedIndex; for ( int Index = 0; Index < Panes.Count; Index++ ) { if ( ( Panes[ Index ].IsHidden || !Panes[ Index ].IsPinned ) && Index <= SelectedIndex ) { SelectedIndex++; } } PaneGroup.SelectedIndex = SelectedIndex; } }
Place a notepad over the MainWindow and mouseover an unpinned pane - the autohide area shouldn't show up.
With three split containers in one other and no document host resizing between the first and second containers causes the first and third containers to resize, instead of the first and second containers.
The compass is out of place when specific height is set to the dock and the window is made smaller than the docking height
Steps to reproduce: 1. Start the WPF Controls Example application on a terminal server 2. Select Docking example 3. Try to move a floating windows by dragging it with the mouse 4. The window will move for a split second, but stop moving after that. (It behaves as if the mouse button was released after the initial move)
1. Create an app using RadDocking. The 'First Look' demo of RadDock can be modified to reproduce the problem. 2. Modify one of the panes, replace the TextBlock control with a TextBox control. Bind the text of the TextBox control to a string property. 3. Add the string property to the .cs file and in the setter, Show a MessageBox. 4. Run app. Select tab with Textbox control and modify the value. 5. Now select the other tab. the messagebox will be displayed. Notice it can be dismissed via keyboard but not via mouse click. It cannot be moved via mouse either. 6. Select a window outside of the application and not select the message box. Notice Mouse input now works. MessageBox can be moved and dismissed via mouse.
If the IsContentPreserved of a PaneGroup is SET to true and a RadTabControl is placed inside a Pane the focus is moved through its content.
Dragging objects from outside control shouldn't be allowed in specific cases. In cases where the RadDocking control cannot use the dragged data, the drop operation shouldn't be allowed.
Removing the Right mouse button ContextMenu of ToolWindow is not possible.
Place one RadPane in a RadPaneGroup. Bind IsHidden property of this RadPane, and set the default value to True. If you change it to False, the width of the AutoHide area is not set to the correct one.
This happens in particular scenario after saving/loading the layout.
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: https://github.com/telerik/xaml-sdk/tree/master/Docking/RestoreFocusOnStateChanged
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.