Progress® Telerik® UI for WinForms Feedback Portal
Back to Feed
Request a Feature Report a Bug
Completed
Last Updated: 27 Aug 2015 15:45 by ADMIN
ADMIN
Dess | Tech Support Engineer, Principal
Created on: 18 Mar 2015 15:19
Category: Dock
Type: Bug Report
1
FIX. RadDock - after dropping a HostWindow it is not positioned according to the Preview
To reproduce:

private void commandBarButton1_Click(object sender, EventArgs e)
{
    Telerik.WinControls.UI.RadForm frm;
    frm = new Telerik.WinControls.UI.RadForm();
    frm.Text = "Test" + num;
    num++;

    Telerik.WinControls.UI.Docking.HostWindow host;
    host = new Telerik.WinControls.UI.Docking.HostWindow(frm, Telerik.WinControls.UI.Docking.DockType.Document);
    this.radDock1.DockWindow(host, this.radDock1.GetDefaultDocumentTabStrip(true), Telerik.WinControls.UI.Docking.DockPosition.Fill);
}

Workaround:
 this.radDock1.TransactionCommitting += radDock1_TransactionCommitting;

private void radDock1_TransactionCommitting(object sender, RadDockTransactionCancelEventArgs e)
{
    if (e.Transaction.TransactionType == DockTransactionType.DragDrop && e.Transaction.TargetState == DockState.Docked &&
       !( e.Transaction.AssociatedWindows.First() is ToolWindow))
    {
        FieldInfo fi = typeof(RadDockTransaction).GetField("targetState",BindingFlags.NonPublic |BindingFlags.Instance);
        fi.SetValue(e.Transaction, DockState.TabbedDocument);
    }
}
Attached Files:
12 comments
ADMIN
Stefan
Posted on: 10 Jun 2015 09:27 
Thank you for your input. We will have it in mind when working on the feature.
Constantinos Petridis
Posted on: 10 Jun 2015 08:31 
The end user needs to know, prior to the actual movement, where the host control will end up.

Whatever decision you make (on the actual functionality of the dock control) the visual cues must be consistent to the actual movement, otherwise the end user will be "puzzled" and complain or (at best) file bug reports.
ADMIN
Ivan Todorov
Posted on: 09 Jun 2015 15:00 
Hi Constantinos,
We are pretty much aware of your requirements and scenario. However, as I mentioned before, this is controversial to the 127550 feedback item (your suggestion for hiding the the docking guides will not work as this will forbid many feasible cases like the default layout of the Visual Style Builder for example). In order to allow the flexibility that you need, we have to extend the central docking guides with 4 new ones as in Visual Studio 2012 but as I said, this won't be included in Q2. For the time being, we can at least change the visual clue so that it displays the actual target bounds, if you think this will make the experience any better. Let me know what your thoughts are.
Constantinos Petridis
Posted on: 09 Jun 2015 08:15 
Visual Studio docking system allows Documents to only dock as documents but toolwindows behave as both toolwindow (in edges) and document (in document area).

My problem is that I use RadDock to host form controls. Each form is hosted in RadDock as a ToolWindow with starting state position Fill inside the DefaultDocumentTabStrip of radDock.

I would expect that dragging this window from the document tabstrip to 
1. centerRight, centerLeft, centerUp, centerDown: the window will be docked as a document splitting the document tabstrip vertically or horizontally (as the visual cue suggests).

2. edgeRight, edgeLeft, edgeTop, edgeBottom: the window will be docked as a toolwindow on the edge of radDock (as the visual cue suggests).

Using the default values of RadDock this is not possible in the latest 2015.1.331 version (was possible up until 2014.2.617). 
To achieve this, one needs to change the DragDropMode of radDock to Preview mode.
Using Auto or Immediate will change the behavior and dock the window always as a toolwindow when dragged centerRight, centerLeft, centerUp, centerDown and edgeRight, edgeLeft, edgeTop, edgeBottom.

I would be fine with using the Preview mode (as I am doing right now) but it still has a bug/problem.
When a window is dragged out of docking as a float window and then dragged in centerRight, centerLeft, centerUp or centerDown, the window is placed as a toolwindow (edge behavior) not respecting the visual cues.

Bottom line is that the end user expects the visual cues to be the final result. It cannot and should not be any different. Either fix the docking or the visual cues and/or allowed dock states...

The mentioned 127550 bug/fix is wrong, if you want to avoid this functionality then you should simply not allow for a toolwindow to dock in the middle center/top/bottom/left/right areas, not to force the docking of a toolwindow as a toolwindow (using the far edges of radDock) but visually showing that the docking will split the main document tabstrip.
ADMIN
Ivan Todorov
Posted on: 08 Jun 2015 13:14 
Hi Constantinos,

It seems that the requirement of this item is in conflict with the requirement of an already resolved one: http://feedback.telerik.com/Project/154/Feedback/Details/127550-fix-raddock-when-a-tool-window-is-dropped-in-the-center-to-top-bottom-left-o
Using the docking guides at the center can only dock a tool window in one of the requested states and we are considering that the correct behavior would be to keep it as tool window. A possible way to resolve the case is to add two separate docking guides on each side, one for docking as a document window and one for docking as a tool window (just like in Visuial Studio 2012). However extending this functionality requires quite a bit of effort and will not be included in Q2 2015. For the time being, you can either use the workaround in the description, or dock a tool window to the center docking guide, then use the context menu to create a vertical split group (see the attachment).

Hope this will help you.
Attached Files:
Constantinos Petridis
Posted on: 11 May 2015 08:20 
Thank you for the update, we will wait for Q2 2015
ADMIN
Stefan
Posted on: 11 May 2015 07:26 
Hi Constantinos,

we are currently working on this item and we hope to have it done for out next release, due in the end of June. 

I hope that this time frame is suitable for you.
Constantinos Petridis
Posted on: 11 May 2015 07:09 
Any news on this? 
We are waiting for a fix before we continue and upgrade our software to use the latest version of UI for Windows.
ADMIN
Ralitsa
Posted on: 06 Apr 2015 08:43 
Hello Constantinos, 

Thank you for the detailed information about your cases and for the provided images.

The described issues will be taken under consideration when working on this item too.
Constantinos Petridis
Posted on: 03 Apr 2015 15:06 
Hello Desislava,
it works better with 2015.1.331 dlls but I still have problems :)

When I create a host window of dockType Document, and try to dock this on the far side of radDock (as a toolwindow), the result is that it is docked in place of the toolwindow but as a document. Is this desired? shouldn't this be docked as a toolwindow?

To have a better understanding of our application.
We are using RadDock to dock multiple forms, opened by users. Our software used to be an MDI container hence we tried to keep the same logic using your radDock control to generate a more fresh UI.
Up until 2014 versions, we did the following to add a form to RadDock:

User selected the form from a menu or command-bar. The form was created (new Form() etc) and was send to a special function of main form (that has a radDock control) that did (more or less) the following:
Telerik.WinControls.UI.Docking.HostWindow host;
host = new Telerik.WinControls.UI.Docking.HostWindow(frm, Telerik.WinControls.UI.Docking.DockType.ToolWindow);
this.radDock1.DockWindow(host, this.radDock1.GetDefaultDocumentTabStrip(true), Telerik.WinControls.UI.Docking.DockPosition.Fill);

HostWindow was using ToolWindow DockType to allow the user to have the same form as a Document and as a ToolWindow (if he/she wants to have the form as an auto-hide toolwindow for example).

Using the above configuration, the 2015.1.331 dlls do not work as we wanted. If we don't use DragDropMode Preview, drag dropping this window will not follow visual cues and will be docked (always) as a toolwindow.
If we use DragDropMode Preview, it works but has the same behavior as described in previous comment (making the host float and then docking it as document to split the main document container, it is docked as a toolwindow).
If we use DockType Document, it works much better but we can't dock the host as toolwindow, though it does dock as if it was a toolwindow, it even shows the correct messages when right clicking the title. If we select auto-hide, from context menu, the visual representation of the form as toolwindow is better but still has problems, and if the auto-hide is unchecked, then the host window is docked as document and not as it was previously, as a toolwindow.

We need to have a host control that will behave as a toolwindow if drag dropped in the places that toolwindows can appear and as a document when placed inside. This functionality was working great until 2014, but was changed in 2015 (even latest developer only version 2015.1.331).

I have attached some examples of odd behavior with 2015.1.331 version
Attached Files:
ADMIN
Dess | Tech Support Engineer, Principal
Posted on: 03 Apr 2015 12:53 
Hello Constantinos,

Thank you for writing.

Following the provided description I was able to reproduce the issue with DocumentWindows when the DragDropMode is set to DragDropMode.Preview. I have updated the workaround accordingly to cover this case as well.

I would like to note that the described issue in this feedback item seems not to be reproducible in the latest version Q1 2015 SP1 (version 2015.1.331). Would it be possible for you to upgrade in order to benefit from all the introduced fixes regarding RadDock. We will perform couple more tests and we will close this item if it passess our QA cycles.
Constantinos Petridis
Posted on: 18 Mar 2015 16:47 
Setting the DragDropMode to Preview does work in most cases. It does not work if you drag a docked window to a floating state and then dragging the window to dock, as shown in the attachments, the window is docked as a toolwindow on the right/left/top or bottom.
Create an account Log In
View
Type
Status
Category