Document tabs are not automatically scrolled

Hi Tobias,

It wouldn't likely be intentional.  The best path forward would be for you to make a new simple sample project that shows this happening, and send that to our support thread, referencing this thread.  Then we will debug the scenario with that.  Please make sure you exclude the bin/obj folders from the ZIP you send so it doesn't get spam blocked.  Thanks!

Hi,

it seems the problem only occurs with certain document types. So far I have identified two controls that produce the problem. One of which is an older version of the WinForms SyntaxEditor with the C# Plug-in.

I thoguht the WinForms/WPF Interop scenario might be an issue, but other WinForms controls (e.g. another SyntaxEditor with custom language) don't cause any problems.

But now I am able to reproduce the issue with the sample browser. Just open the "Simple IDE" in "Docking/MDI" demos and create some C# documents until the tabs are overflowing. Now close some documents while a C# document is open. The tabs are not re-arranged. If a text file is opened, everything works fine. Likewise, switching to a C# file doesn't do anything, but switching to a text file causes the tabs to update.

I should add that we are using the following properties in our dock site:

AreNewTabsInsertedBeforeExistingTabs="False"
IsTabLayoutAnimationEnabled="False"

Hi Tobias,

Thank you for the steps to reproduce this.

Oddly, it seems to be the presence of a visible NavigableSymbolSelector control that is triggering it.  The NavigableSymbolSelector is visible in C# document windows in that sample.  If you always keep the NavigableSymbolSelector hidden, even in C# documents, then they work as expected.

It's strange because the NavigableSymbolSelector is in the client area of the DocumentWindow, which shouldn't have any effect on the tabs.

We've found a way to trigger a scroll check based on when the Panel's children change, and that seems to work around this.  The code change will be in the next maintenance release.

I might add that our C# editor does not have the NavigableSymbolSelector and the other editor is completly different. But yeah, it is probably something that the editor control causes. I will check out the next release.

Hi Tobias,

It had to do with something where the Panel containing the tabs requested measurement and we measured it at less overall width, but yet the subsequent arrange call was still stuck at the larger original width when a NavigableSymbolSelector was present in the document window.  The NavigableSymbolSelector doesn't have anything special inside of it, it just arranges to its size.  

Anyhow, if you'd like to test our workaround prior to official release (probably a good idea), please write our support address and reference this thread.  We'll send you a preview build to try.