DocumentWindow is empty after split

Docking/MDI for WPF Forum

Posted 7 years ago by Kasper
Version: 11.2.0552
Platform: .NET 4.0
Environment: Windows 7 (64-bit)
Avatar

Hi guys,

I have a pretty strange problem that I hope you can help me with. I have a very Visual Studio-like layout, with Tool Windows to the left, to the right and in the bottom of the screen. In the middle, I have a TabbedMdiContainer/Host, which I add DocumentWindow instances to. Each DocumentWindow contains a SyntaxEditor control.

Everything is working very well, but if I split the area, either by dragging a DocumentWindow and placing it beneath the other or if I right click the tab and select "New Horizontal/Vertical Tab group", the DocumentWindow "left behind" gets an empty space instead of the SyntaxEditor. Now, if I create a new DocumentWindow in the top container, where the empty one is, and then shift back to the empty one, the SyntaxEditor is back and everything appears normal, but until that, the first DocumentWindow is useless.

Do you have any idea what could be causing this? I have tried re-creating the problem with a more simple layout, but so far no luck. I have also tried looking at the application with WPF Snoop, but with no luck. I hope you have some suggestions, because this is a pretty serious problem :)

Comments (10)

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Kasper,

That sounds like an issue we have previously corrected. I believe the other issue was corrected in WPF Studio 2011.1 build 0543. Are you sure you are running the latest version?

If so, then we would need a small sample project that reproduces your issue so we can take a closer look.


Actipro Software Support

Posted 7 years ago by Kasper
Avatar

Hi,

It appears that I'm using version 11.2.552.0 - is that not the latest? If you announced a version later than that, I must have missed the announcement. I can't find anything about it on the blog.

Posted 7 years ago by Kasper
Avatar

Also, as I stated in my initial post, I haven't been able to reproduce this in a sample application, but if this is a bug you have seen before, then maybe it hasn't been fixed for all situations? I have spend a lot of time trying to pinpoint what is causing this, but I can't seem to find the cause of the problem. Hopefully you can tell me more, with your intimate knowledge of how the controls work :)

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Kasper,

Yes, 2011.2 build 0552 was released after 2011.1 build 0543 and includes the fix to the previous issue. Unfortunately it would be impossible to correct what you are seeing, as we have no idea under what circumstances it occurs.

The previous issue was related to setting TabbedMdiHost.TabOverflowBehavior, which was inherited by the TabbedMdiContainer's. Hopefully that will help you narrow down the issue.


Actipro Software Support

Posted 7 years ago by Kasper
Avatar

Unfortunately this bug is too serious to just ignore. I was setting the TabOverflowBehavior, but neglecting to set it or setting it to e.g. None didn't fix the problem. I have tested this a bit more, and here are some facts that I hope can help you help me:

  • SyntaxEditor has nothing to do with it - it happens with a simple TextBox as well.
  • I can change back and forth between two documents, where one of them are in "blank" mode, but it will remain blank until the tab has been in the background, either because I have added another tab or moved the old one back so they are in the same group.
  • It happens whether I use the conext menu or drag and drop and for both vertical and horizontal splits
  • It does NOT happen if I float the document instead of placing it in a new group
  • If I have 3 documents and move Doc3 to a new tab group, Doc2 is blank. If I then move Doc2 to another new group, NO documents are left blank!

Please let me know if there's anything else you want me to try, that can give you a clue to what is going on.

If you can't help me fix it, then perhaps you can figure out a workaround. I really need this to work and I haven't yet found a way to reproduce it in a simpler app but it IS happening and I can't really offer this sort of bug to my paying customers.

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Kasper,

We are certainly not tring to ignore this issue, but we need a reproducable case to both determine and test any possible fixes.

If you can only reproduce this in your application, you may try stripping out styles/settings/functionality little by little until you no longer see the issue. That may help narrow down the ultimate cause and create a reproducable case.


Actipro Software Support

Posted 7 years ago by Kasper
Avatar

It cost me yet another couple of hours, but I finally figured out what causes this problem. On my TabbedMdiHost, I have a line of code that sets the DocumentName of my RibbonWindow to the filename of the document that just got focus. For some extremely strange reason, this is all it takes to experience this issue. I don't know what goes on behind the curtains of that property, but hopefully you can figure it out, now that I've tracked down the cause. To see it for your self, try adding an eventhandler like this to the TabbedMdiHost:

private void TabbedMdiHost_PrimaryWindowChanged(object sender, DockingWindowPropertyChangedRoutedEventArgs e)
{
	this.DocumentName = e.NewValue.Title;
}

I have e-mailed you a sample application as well. I'm looking forward to hearing what caused all this trouble :)

Answer - Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Kasper,

Thank you for the sample application. This is indeed related to setting the DocumentName property on the containing RibbonWindow. This ulimately forces WPF to perform a layout in order to properly display the RibbonWindow's title bar. But this is actually occuring while the WPF is in the process of performing a layout, which causes the problem you see (where the ContentControl doesn't properly display it's content).

We have updated the RibbonWindow to dispatch the code that forces the layout update to ensure it does not happen while WPF is currently updating the layout. This will be in included in the next maintenance release.

In the interim, you can work around this issue by dispatching your code like so:

private void TabbedMdiHost_PrimaryWindowChanged(object sender, DockingWindowPropertyChangedRoutedEventArgs e) {
	this.Dispatcher.BeginInvoke((Action)(() => {
		this.DocumentName = e.NewValue.Title;
	}));
}


Actipro Software Support

Posted 7 years ago by Kasper
Avatar

Unfortunately, this problem does not seem to be entirely fixed. It now works in my sample that I also sent to you, but the problem remains in my real application. Fortunately, your workaround seems to help, but it would be great if it wasn't required.

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Kasper,

As always, if you can send us a sample we'd be happy to address the issue. Thanks!


Actipro Software Support

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

Add Comment

Please log in to a validated account to post comments.