Docking MDI - Switching tabs unloads inactive DocumentWindows

When you say rebuilding, are you referring only to the time required to perform layout and rendering?  Or are you doing some other intensive work in response to the control's Loaded event?

I'm mostly referring to the time required for layout & rendering - I'm working with a rather poorly designed user control which I cannot change. I've tried various things to preserve the visual tree, but with no success.

Ah.  Well, as I understand it, unloading the content of windows that aren't selected was one of the explicit design goals when Actipro rewrote their docking framework for the 2016 release.  I'm not sure there's a way around it.  Out of curiosity, have you tried using cached composition on your UserControl?

One way to make the change feel less jarring might be to replace the docking window content with a simple loading indicator when it is unloaded (or even a bitmap of the original content), and then insert the real content again after the window is reactivated.  At least then the tab would seem to change instantly, even if there is a pause afterward while the control gets swapped in.

Alternatively, the legacy docking framework (ActiproSoftware.Docking.Legacy.Wpf.dll) keeps the tab content loaded, but using it is not advised.

Thank for the answer Mike! I suspect caching won't really help in my case.

As far as using the legacy framework, I'd stay away from that since I'd really like to use the newer features. 
So far, from the info I've been able to gather, you're assessment seems pretty accurate. I suspect my best bet would be to manually rebuild the visual tree.

Hi Cristian,

The tabbed MDI works similarly to a normal WPF TabControl where only the selected tab's content is loaded at a given time.  If all the unselected tab content was also loaded, that would drag layout performance down on window resize, etc. if you had many tabs open.

You mentioned it's taking a while for you when you switch tabs due to layout/rendering of a UserControl you're using.  Have you done any performance profiling of it to see if there is anything you can update on it to help?  It's from a third party and you don't have access to update its design?

Are you using inherited data contexts (from the DockSite or above) for your UserControl?  Sometimes that can lead to performance issues on tab changes if a complex control initially had no inherited DataContext (since it was outside the visual tree) and then got added to the visual tree and had to data-bind and lay itself out again.  You can work around that by following the steps in the "Document/ToolWindow DataContext Cleared On Layout Changes" section in the Docking/MDI Troubleshooting documentation topic.  I wonder if that could help performance a bit for you.

Thanks for the reply - I fully understand why inactive tabs are being unloaded; it's not the case with my application as no resizing will be done and the users will not be dealing with a large number of tabs.

The user control I'm mentioning is something like a bad inheretance :) - which is why I'm trying to work around it. I don't have access to the original source code nor do I think it would pay off to try to modify it. It has been successfully used (as a hosted element) in a legacy Windows Forms application. To tell you the truth, I suspect layout changes were not even taken into account to start with.

To asnwer your last question - no, we aren't using inherited data contexts.

This is why I was asking if there were any quick workarounds (maybe something to stop unloading the DocumentWindow) or if there are any other alternatives that would give the same look and feels as multi-tabbed MDI.

Hi Cristian,

All this happens in the AdvancedTabControl control's template.  AdvancedTabControl is used wtihin the TabbedMdiContainer and ToolWindowContainer templates.  There is a ContentPresenter in it that is bound to the SelectedContent property.  The only way to really achieve what you want would be to make a custom Grid in place of that ContentPresenter that attaches to the tab control and watches for item changes.  It then would have to inject each tab's content into the Grid and update it as tabs change.  It would also have to make sure that the selected tab's content is either highest in z-order or else you set all other non-selected tab content elements to have Visibility="Hidden" (instead of Collapsed).  I'm not sure if the latter would help solve the problem, but Hidden generally means still lay out the controls, just don't render them.  That's the only suggestion I have for this, sorry.

Thank you very much for the support and ideas thrown out.

We're most likely going to go with re-working the user control from scratch as it does not seem like a very robust solution to mess up with the internal workings of the dockin suite controls. This should help us with future development as well.

Kind regards,
Cristian