How to mimic document behavior with tool window while dragging?

Hi Greg,

I'm sorry but I don't think I'm seeing the same thing.  Both document and tool windows should be behaving the same when you drag.  Both are changing tab order for me when within the same container.  Once I drag out of the container, it moves to a floating container and drags around with highlights until you drop it.  Can you tell me how to reproduce what you are seeing in one of our samples if it is different?

If you set the DockSite.UseDragFloatPreviews property to false, then the behavior for both document and tool windows should still allow tab reordering in the same container, but dragging outside of the source container will only use highlights.

Thank you for the reply.

Assuming the following DockSite properties:

UseDragFloatPreviews    = false,
CanToolWindowsFloat     = true,
CanDocumentWindowsFloat = true,

everything works as you've described.

When using these properties:

UseDragFloatPreviews    = false,
CanToolWindowsFloat     = true,
CanDocumentWindowsFloat = false,

in this case, documents will always use previews when being dragged within the MDI host.

For these settings:

UseDragFloatPreviews    = true,
CanToolWindowsFloat     = true,
CanDocumentWindowsFloat = false,

tool windows use previews as well while being dislocated from the DockSite, but when they are in the floating state, they don't show previews anymore when they are being dragged (and I think that this is intended/by design).

And finally, when using these settings:

UseDragFloatPreviews    = true,
CanToolWindowsFloat     = true,
CanDocumentWindowsFloat = true,

tool windows and document windows use previews while they are dislocated from the DockSite, but when in floating state (either tool windows or document windows), they do not show previews anymore when being dragged.

So basically

UseDragFloatPreviews    = true,

partially solves my requirements; partially because once a tool window/document window is floating, when they are being dragged, they don't show previews anymore- they're being dragged as regular windows.

If this behavior is intended/by design, I understand; so I guess that the simpified form of my initial question is if it's possible to use previews when dragging floating tool windows/document windows?


As a side note, more or less on the subject, I've tested this behaviour in DevExpress's "WPF Dock Windows" product, but I prefer your docking solution for several reasons. I strongly believe that competition leads to better products for the consumers, which can be clearly seen on the WPF controls market today, my top three favourites being Actipro, DevExpress and Telerik (all with exclusive controls, strong and weak points), but when it comes to precision and attention to details, the real competition is between Actipro and DevExpress, and I would say that your docking and ribbon solutions are directly comparable to DevExpress', both being similar, looking slick and working smooth, and at the same time both presenting features that would complement one and the other perfectly, so I'm feeling torn, but I tend to lean towards Actipro mostly because of specific aesthetic/functional features that I consider are more important and/or better refined.

Hi Greg,

Thanks for posting the detailed findings.  Yes, the behaviors you described are all intentional and by design.  In cases where a docking window kind is prevented from being able to "float" then we can't throw it in a rafting container for dragging purposes so we kick it over into using float previews.  

To directly answer your question about using previews when dragging floating docking windows, we don't have an option to enable that.  There are three thoughts behind that.  First, the main reason to use drag/float previews is to prevent any additional layouts from occuring when dragging.  In the case of dragging an already-floated docking window, it's just moving the existing WPF Window that contains it and isn't triggering additional layouts.  Second (and perhaps most important), it allows you to move the floating docking window to see what's behind it.  Third, by using native Win32 window move logic, we can take advantage of Aero snap and similar features that are baked into windows.  I hope that explains the logic better behind it.

And thanks for your other comments.  We've done our best to make Docking/MDI the most beautiful and flexible docking window system out there, including features like subtle animations throughout, full MVVM support, etc.  

Thank you for the explanation. Everything makes sense; the reason I was attracted to the idea of having previews even for already-floated tool/document windows (as an additional option) is that their content wouldn't have to move while they're being dragged, which helps removing stuttering in some cases (because I've noticed that performance can degrade during a drag-and-drop operation if the dragged window has a complex interface).

Since previews for already-floated windows is not an option, I think that the alternative would be hiding/collapsing a windows controls container and making it visible again when the dragging operation has finished. In this regard I haven't been able to identify any pertinent events that I can subscribe to in order to implement this behaviour. Could you tell me if there's a way I can detect when a tool/document window enters and leaves the dragging state/operation?

Thank you.

Hi Greg,

Could you put together a new small sample that would show the performance degradation you mentioned so that we could see it in action?  I wouldn't expect there to be any if you are simply dragging a WPF window (that contains the floating dock host) around since there shouldn't be any additional WPF layouts occurring within the WPF window itself in that scenario.  Please send the sample to our support address and mention this thread.  Be sure to remove any bin/obj folders from the ZIP you send and rename the .zip file extension to ensure it doesn't get spam blocked.  Thanks!

We do have DockSite.WindowsDragging/ed events that fire before/after one or more docking windows are dragged.

Ah, yes, I see the DockSite WindowsDragging and WindowsDragged events, these should do the job.

"Could you put together a new small sample that would show the performance degradation you mentioned so that we could see it in action?"

When I mentioned performance degradation while dragging windows, I wasn't referring to the tool/document windows specifically (sorry if I made it sound that way), but to WPF windows in general, and it's something I've observed happening during my past years of experience with WPF.

Basically if there was a window with a lot of UI elements in it (animating or static or both), the window would stutter while being dragged, but I think that has to do mostly with system specifications (CPU, GPU, hardware acceleration settings, etc.), so it's not something that all users experience the same way, but using previews when dragging windows (or at least hiding content during the drag) would guarantee smooth movement, regardless of the window content, and that's why I was interested in this.

Obviously, tool/document windows aren't meant to host complex UI layouts, so it shouldn't be a problem anyway, but I like to know I have the option/solution in case it's needed.

I don't think I can present a relevant sample project to demonstrate the stuttering because I can hardly make it happen on my own system, but I guess if an absurd amount of controls would be stuffed into a window and with looping animations, the effect can be noticed. Either way, as I said before, that would be related to the machine the WPF application is running on, and not a set of controls in particular.

Thank you for the support and provided information.