How to mimic document behavior with tool window while dragging?

Docking/MDI for WPF Forum

Posted 8 months ago by Greg Kilmatead
Version: 18.1.0675
Avatar

Hello,
currently, from my observations, the way Actipro docking works with documents (in the tabbed MDI) while they are being dragged is that when dragging starts, the document tab doesn't change its position during the dragging operation, it gets relocated only after the dragging operation ends.

Another observation is that when a tabbed document is being dragged, a preview of it is being used and that the preview doesn't show the contents, only a filled frame which represents the actual tabbed document.

In my opinion, that behaviour is excelent for performance, because the content of a tabbed document never has to move while the dragging operation is active.

Tool windows on the other hand do not work like that at all. When a tool window is being dragged, it gets removed from its docked position and its contents move with it during the dragging operation, which sometimes can cause a lot of stuttering/performance issues when the content is complex.

So my question is, are there any options to make tool windows behave like tabbed MDI documents while being dragged?

If not, at least what would be the C# solution to hiding a tool window's content while it is being dragged?

Thank you.

Comments (6)

Posted 8 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 8 months ago by Greg Kilmatead
Avatar

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.

Posted 8 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.  


Actipro Software Support

Posted 8 months ago by Greg Kilmatead
Avatar

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.

Answer - Posted 8 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 8 months ago by Greg Kilmatead
Avatar

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.

[Modified 8 months ago]

The latest build of this product (v2019.1 build 0683) was released 2 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.