Nov 4, 2009 at 4:46 PM
Edited Nov 4, 2009 at 4:48 PM
First of all, thanks for creating a great library and providing it for free. So far I'm enjoying working with it, and it definitely fills an important need.
It appears that DockingManager can't be fully utilized when it is contained within an Auto-sized Column. Here is some sample Xaml code demonstrating the problem:
The DockableContent displays, and you can click the pushpin to undock it. The anchor tab displays (vertically) on the Left, as expected. However, the flyout window doesn't appear when you hover over or click on the tab.
The specific reason this occurs can be found in DocumentManager::UpdateFlyoutWindowPosition. You set the MaxWidth of the flyout window to the ActualWidth of the DockingManager. In this case, because the DockingManager is auto-sized, its ActualWidth
is the same as the width of the tab panel (approximately 22 pixels in aero). That means the MaxWidth of the flyout window is always set to 0. Here's the code that does that:
_flyoutWindow.MaxWidth = ActualWidth - leftTabsWidth;
My main question is whether there is some reason why I shouldn't expect to be able to use DockingManager in this way. I need to, because my ultimate goal is to use DockingManager in a more complex layout, where the column (or row) containing DockingManager
"collapses" when I undock the contents, thus allowing other parts of the layout to make use of that space. If I were to set a specific width for DockingManager or use some other value for ColumnDefinition.Width, I wouldn't be able to achieve
My initial thought is that setting MaxWidth there would seem to be unnecessary. In this specific case, the application works as expected when MaxWidth isn't set. However, if you change ColumnDefinition.Width to *, the flyout window does extend
beyond the edge of the application window's usable area (by what I would guess is the width of the anchor tab panel), so I can see why setting MaxWidth would be necessary in other cases.
With that in mind, I could see a couple of options. One is to only set MaxWidth if DockingManager.ActualWidth > leftTabsWidth; essentially, that would be like saying "if I believe the DockingManager has been auto-sized, don't worry about MaxWidth".
The other option is to set MaxWidth (and MaxHeight in other cases) based on the boundaries of the application window, if that is the "bad condition" you're trying to avoid by setting MaxWidth.
What do you think?