Visual Studio 2010 document window behavior

Our application embed a RadDock element.Unfortunately, in a non-systematic way, our application crash with this stack trace: 

Our application is a 64bit application (we migrated it to NET6 using Telerik 2022.2.510.60). As I told unfortunately in this case I'm not able to isolate the case in a simple project (as I'm used to to).

It would be useful by your side, however, make a check to the last trace line of the log I've gave to you: 

 at Telerik.WinControls.UI.ThemedFormBehavior.OnWMNCHitTest(Message& m)

If I decompile your code I find this:

L_param, returned in (1) is an IntPtr that, on a 64bit machine running a 64bit application could contains a value that SOMETIMES will crash in (2) where you try to convert it with an IntTo32 method...

99 time to 100 the code in line 755 works fine but I think that it is not guaranteed that L_Param returned in (1) can be fit in a 32bit box. This could explain why I use the phrase "...in a very random way" and why, at the moment, I'm not be able to give you a simple application where the problem is systematic.

I suspect that at line 755 we have got a problem, I'll appreciate your point of view about it.

Use attached to reproduce.

Tested on Windows 10 (1607 and 1703)

Workaround:

RadControl.EnableDpiScaling = False

Visual Studio 2010 introduced the concept of document windows which behave like a regular tool window. Implement the same functionality within RadDock.

using the RadDock component in a product that must support multiple montors.  I see some mention of this in the support forums, but I would like to confirm with you that RadDock does support docking on multiple monitors with dragging of panes/panels between monitors and full serialization of the layout on multiple displays. Add support to move and maximize DocumentWindow and ToolWindow in multimonitor system.

In addition, if this ContextMenu is called from a control contained in an autohide DockWindow that is currently expanded, this window becomes collapsed.

RadDock should have ActiveMDIChild property which returns the currently activated mdi child.

Resolution: 
Use the ActiveMDIChild property of the parent form. 

When a floating window is hidden and RadDock layout is saved, the hidden window is saved in its Docked state and displayed as Docked when layout is loaded.

One should be able to drag and drop a ToolWindow to the ToolWindows area even if this ToolWindow is currently docked in the DocumentWindows area, similar to the VS2010 behavior.

To reproduce:
Use the approach here:  http://docs.telerik.com/devtools/winforms/dock/object-model/customizing-floating-windows

Workaround:
private void RadDock1_FloatingWindowCreated(object sender, Telerik.WinControls.UI.Docking.FloatingWindowEventArgs e)
{
    e.Window = new MyWindow(radDock1);
    e.Window.FormBorderStyle = System.Windows.Forms.FormBorderStyle.Sizable;

}

class MyWindow : FloatingWindow
{
    public MyWindow(RadDock dock): base(dock)
    {

    }
    protected override CreateParams CreateParams
    {
        get
        {
            CreateParams cp = base.CreateParams;
            cp.Style |= NativeMethods.WS_THICKFRAME;
            return cp;
        }
    }
}

Trying to Double-Click ToolWindow to dock it back on RadDock as a Tab...

When you set a ToolWindow to only AllowedDockStates of Floating,TabbedDocument and Hidden, you lose the header double-click functionality of the toolwindow that pops the ToolWindow out as a floating window as well as pops it back in as a tabbed document. If you add AllowedDockState of Docked, the double-click functionality works. 

I am working with ToolWindows on a RadDock control and want them only represented as either Floating or TabbedDocuments with the ability to double-click a floating window caption and pop it back onto the RadDock control as a TabbedDocument. I got the double-click functionality to pop a floating window back in by using DockStateChanged and TransactionCommitment events. The less important one of double-clicking on a TabbedDocument header to pop it back out I have not yet done.

I use the DockStateChanged event to fire when ToolWindows are set to floating and change the AllowedDockState of that window to use Docked. I use TransactionCommitment to change a ToolWindow's AllowedDockState to exclude Docked and programmatically change the DockState of the window to TabbedDocument. Is this the best approach or did I miss a simple property or something? I pasted the two methods below for your convenience.

Resolution: 

In Q1 2014 (version 2014.1.226) we introduced an floating option for tabbed document which resolved this issue. 
Here is the link to the feedback item: http://feedback.telerik.com/Project/154/Feedback/Details/111942-improve-give-floating-option-for-tabbed-document

A nice addition to the existing save/load layout functionality of RadDock will be the possibility to save the AutoHideSize value.

I put a tree on toolwindow (the tree Nodes are chekbox)  , when I autohide the toolwindow and show it again the font of tree nodes change and also the nodes which were checked change to uncheck

We have a somewhat complicated application in which we have a RadDock inside another RadDock.
Everything seems to work just fine, with one exception.

When we resize the application window itself, the ToolWindow and DocumentWindow controls don't properly redraw their areas..

It is caused when you open the solution for the first time, open the FrmUmre in design time, change the active window in RadDock and run the application. 

The error states: "The control Telerik.WinControls.UI.Docking.DocumentTabStrip has thrown an unhanded exception in the designer and has been disabled"

If there is a RadDock in UserControl and second UserControl, which inherits the first one, then the RadDock€™s layout in the second UC is damaged in design and run-time.

support of Pin tab operation in DocumentContainer of RadDock

Dock windows should keep its icon and image that is set for them in a previous state, no matter their form, tabbed, docked,

as magnetic behaviour I mean that when you move a window close to another window, the first window just snap to the other. The same behaviour is fine when you resize a window.
The magnetic behaviour helps you to arrange floating windows into the screen, so people dont get crazy trying to align and resize all the floating windows around in the screen.

This feature request refers to introducing a new ToolWindow property which will allow setting individually text to the ToolWindow's Caption and Tab.