This happens because in the current version of Telerik, the IsTopmost of the ToolWindow that host the floating pane is set to True. That was needed for a related new functionality, but it brings a major behavioral change in the RadDocking control.

To work this around, you can subscribe to the ToolWindowCreated event of RadDocking and set the IsTopmost property of the creating ToolWindow to False.

private void RadDocking_ToolWindowCreated(object sender, Telerik.Windows.Controls.Docking.ElementCreatedEventArgs e)
{
    var window = (ToolWindow)e.CreatedElement;
    window.IsTopmost = false;
}

In OS two monitors are configured: monitor 1 (3840x2160) scale: 200% and monitor 2 (1920x1200) scale 100%.

Our wpf application has a main window, maximized on screen 1 and a child window maximized on screen 2.

In the app.manifest we use per monitor dpi awareness:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
  <windowsSettings>
    <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">True/PM</dpiAware>
    <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2,PerMonitor</dpiAwareness>
  </windowsSettings>
</application>

Both windows have a RadDocking instance with a docked RadPane like:

<Grid>
  <telerikDocking:RadDocking Name="Docking"                              
                             HasDocumentHost="True" 
                             telerik:DragDropGroup.Name="VDDragDropGroup">
    <telerikDocking:RadDocking.DocumentHost>
      
            ...
          
    </telerikDocking:RadDocking.DocumentHost>
    <telerik:RadSplitContainer InitialPosition="DockedBottom">
      <telerik:RadPaneGroup>
        <telerik:RadPane Header="Test Panel" IsDockable="True">
          <Border Background="Green">
            <TextBlock Text="Test Panel" HorizontalAlignment="Center" VerticalAlignment="Center"/>
          </Border>
        </telerik:RadPane>
      </telerik:RadPaneGroup>     
    </telerik:RadSplitContainer>
  </telerikDocking:RadDocking>
</Grid>

If you drag and move the docked panel from screen 2 to screen 1 the compass at screen 1 is only shown if the mouse position is in the first quadrant of screen 1 . The compass is shown on the correct place but cannot be activated, so that no dropping is possible.

Without unsing per monitor dpi awareness everything works fine. Unfortunately we must use per monitor dpi awareness for our application.

This bug is also reproducable in V2023.3.1218.

When a RadSplitContainer with Orientation="Vertical" contains RadPaneGroup instances, resizing them causes a flicker when the ShowResizePreview property is set to False. This happens with the VisualStudio2019 theme.

For the time being, a possible workaround is to create a global Style with TargetType="RadPaneGroup" and set the Margin property to "0":

<Style TargetType="telerik:RadPaneGroup" BasedOn="{StaticResource RadPaneGroupStyle}">
    <Setter Property="Margin" Value="0"/>
</Style>

The DataContext of RadPane's content is lost when showing its preview in the DockingNavigator.

As a workaround, you could set the DataContext of the content element could be set explicitly.

The RadOutlookBar control takes a significant amount of time to load initially when it does not have a fixed width and its IsMinimized property is explicitly set to True.

A possible workaround, for the time being, is to set a fixed Width for the control and change its value in the Minimized and Restored events.

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}

The AutoHide area is closing when clicking at WinForms control placed in it.
The issue also can be reproduced with WebBrowser or any object of MarshalByRefObject type placed in the AutoHideArea.