We are currently replacing an old Infragistics docking manager with your control, and with the old code, we've prevented the floating of windows.
However, the user could still move panes around to a different location, and change the layout (Just like with DragDropMode is set to Deferred).
I would like to support the legacy mode (Which will be the default) which will behave just like the Deferred DragDropMode. I also want the user to be able to change an option in the program, which will change the DragDropMode to Immediate.
This, however, doesn't work as expected...
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.
14 Answers, 1 is accepted
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.
Thank you for pointing these problems out and logging them in Feedback Portal.
We are aware of some of them related to switching the RadDocking.DragDropMode in runtime and with the Deferred mode. You can also track their progress in our Feedback Portal: http://feedback.telerik.com/Project/143/Feedback/Details/113624-when-dragdropmode-is-set-to-deferred-and-the-layout-is-changed-and-saved-some-pan, http://feedback.telerik.com/Project/143/Feedback/Details/125238-the-compasses-dont-disappear-when-reordering-the-panes-in-dragdropmode-deferred
I've updated your Telerik Points as a small token of appreciation for your efforts.
I'm guessing that the bug with the saved layout, and panes that are not being rendered correctly is referring to the forum thread:
Am I right?
If so, I've looked at the layout xml, and it seems that there is empty split container (without any panes or even groups) inside another split container.
Is the solution of removing all the empty split containers on the save layout is a good solution? (meaning, it will not cause problems)
I'm using the following code:
My assumption is that any SplitContainer that doesn't contain any RadPaneGroup is a leftover that shouldn't be there.
Is this solution safe?
In addition to my previous question, is there a way to disable panes reordering in Deferred mode?
AllowDragReorder is not effective in this case. I've debugged the code, and I see that the DragCompleted event never reaches the pane on certain cases, and it happens because the Grid that is being registered to the DragDropManager events is being removed from the visual and logical tree.
Regarding your first question about the empty RadSplitContainers being saved in the xml - this might be caused by the fact that the specific split container has SerializationTag set while its child elements do not. This causes our save/load layout implementation to persist only the split container and not its children.
Removing the empty RadSplitContainers should not cause any issues, so give it a try and let us know if it works in this scenario. Keep in mind that when this xml is loaded - first the RadDocking will be cleared and then the xml will be loaded - and if there are empty split containers tags we will still create (or take from the cache) a corresponding split container and add it in the RadDocking.
Regarding the second question - is there a way to disable panes reordering in Deferred mode?
I've prepared a sample project demonstrating how to achieve that for a RadPane that has the property CanFloat set to false.
The approach consists of adding handler to the DragInitialize method and canceling it if the RadDocking.ActivePane has CanFloat = false. Similarly, you can use a property best suitable for your scenario:
Please find the project attached. Hope this helps.
Actually, my last question was on preventing reordering (and not the placement of panes in another location using the compass).
I'm trying to workaround the bug that the compass don't disappear in deferred mode.
In the RadPane, you have the function SetAllowDrag:
This function fails on some cases, since child is being removed from the visual tree, and from its parent (the RadPane), hence the DragDropCompleted event of is not bubbling to the RadPane.
If I set the allow drag on the RadPane itself, other than its child, meaning:
DragDropManager.SetAllowDrag(this, dragDropMode == DockingDragDropMode.Deferred);
Then I see that the compass disappears, and that the DragDropCompleted event is being received by the RadPane. What are the risks of this change, if any? (for example, null reference, memory leaks, other types of bugs).
Actually, once our code was setting the AllowDrag to the Pane itself as you have found out:
However, that will cause another issue - when there are any UI Elements placed inside the Pane as a content the Pane will be able to be dragged by clicking on this UI Elements. Because of that we fix that issue by setting the AllowDrag to the child. Because of that we do not recommend you to use the workaround you have found. Unfortunately, we could not suggest you any other proper workaround, so please follow the item if you haven't done it yet and as soon as the issue gets fixed you will be notified.
We would like also to ask you some questions regarding the following item:
Indeed as you have found out the issue is caused by the empty SplitContainers that are saved inside the XML file. However, we investigated the issue further and it seems that is has already been fixed with version Q2 2013 - since that version we are no longer loading the empty SplitContainers and because of that the issue should not be observed. Could you please confirm that you are observing the issue with our latest released version Q1 2016 SP1? If you are please, sent us a sample project that reproduces it.
We are looking forward to hearing from you.
Are you sure this bug is fixed? It is marked as approved, not fixed.
Anyway, here is the project:
I've compiled it with the 2016.q1.217.40 binaries, and I've removed them from the rar (in order to protect your assemblies from misuse by someone else).
Just follow the instructions at:
Drag the Boven pane to the left side, and then drag the Onder pane to the pane side, under the Boven pane.
Close the application and run it again. The layout will be loaded from the xaml, leaving an empty space at the right side due to an empty split container.
You are correct, setting the Allow Drag on the pane itself does cause the problem you've mentioned.
I have noticed that the problem seems to happen only for panes in the Document Host (and I didn't understand why)... So I've debugged it a little further, and found out that since the re-ordering is removing and adding the pane from the group, a ClearContainerForItemOverride and then PrepareContainerForItemOverride are being called.
The first one is setting the IsInDocumentHost to false, and the second one to true again, which causes the template to be applied again. This is because of :
Since tabs reordering does not change the IsInDocumentHost, then this is just a side affect that should be ignored,
I have coded a workaround, which is ugly, and not considered bad coding, so if you can think of a better solution, or see any problem with this solution, then please comment.
I have created an internal bool inside the RadPane, called IsBeingReordered (default value is false).
Now the OnIsDocumentHostChanged code is:
And the RadPaneGroup.ReorderTwoNeighbourPanes code changed to this"
By this way, I prevent the extra ApplyTemplate calls.
Thank you for the provided sample project in your previous response. Using it we were able to reproduce again the issue on our side - it seems it has been partially fixed. I am glad to inform you that we have decided to rise the priority of that issue and currently our development team is working on it - as soon as it gets fixed if you have followed the item you will be notified.
As about your latest response. We checked the workaround you have found and it seems a nice one. However, please notice that we cannot guarantee that it will work flawlessly in different scenarios and you might need to test it further.
We hope the provided information will be helpful for you.
I have tested my solution a little further, and there are some cases that it doesn't work (Since the reordering is being done on different events, like TabStripPanel Drop handler, or RadPaneGroup Drop handler (There is maybe another one or two more handlers that I forgot to mention).
In this case, I'm going something like:
reorderedPane.IsBeingReordered = reorderedPane.IsInDocumentHost == radPaneGroup.IsInDocumentHost;
(In order to still support cases when a pane is being moved from the document host to a different location, or vice versa);
And after those fixes, it seemed to be working correctly on all cases I've tested. I just don't like the fact hat I'm setting and resetting a flag.
Thank you again for sharing your solution with us. From the provided description and code of the solution it seems to be a good one and we will definitely check it when the time for fixing the issue comes.
Meanwhile if you have any additional questions or concerns regarding Telerik controls, please do not hesitate to contact us.