Problem with Window.SizeToContent = SizeToContent.Width

Docking/MDI for WPF Forum

Posted 1 month ago by Dirk Zellerfeld
Version: 20.1.1
Platform: .NET 5.0
Environment: Windows 10 (64-bit)
Avatar

Demo XAML:

<docking:DockSite>
    <docking:SplitContainer Orientation="Vertical">
        <docking:SplitContainer>
            <docking:ToolWindowContainer>
                <docking:ToolWindow
                    Title="Bla"
                    ContainerDockedSize="270,200"
                    ContainerMinSize="150,150" />
            </docking:ToolWindowContainer>
            <docking:Workspace x:Name="workspace">
                <docking:TabbedMdiHost x:Name="tabbedMdiHost" />
            </docking:Workspace>
        </docking:SplitContainer>
    </docking:SplitContainer>
</docking:DockSite>

Demo C#:

private void Window_PreviewMouseDown(object sender, MouseButtonEventArgs e)
{
            this.ResizeMode = ResizeMode.CanMinimize;
            workspace.Visibility = Visibility.Collapsed;
            this.SizeToContent = SizeToContent.Width;
}

I would expect the form gets shrunk to the width of the ToolWindow but instead it gets expanded to the whole desktop. Whats the best way to get SizeToContent to work, preferrably without breaking MVVM too much (at the top its just demo code, in our application we use MVVM and things are bound back to a point where accessing UI controls is hardly doable)

Comments (1)

Posted 1 month ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Dirk,

It looks like our SplitContainerPanel (used inside SplitContainer) MeasureOverride is getting called by WPF with the desktop size as the available size in this scenario. If an infinite available size was passed in, we were returning the desired size. Whereas if a finite available size was passed in (as in this case), we were trying to return a value indicating the split container would fill that content, so we returned the availableSize value. This is what caused the problem.

If we always return the desiredSize value instead, it resolves your issue and doesn't seem to cause any additional problems from what I can tell since ArrangeOverride will still perform the normal layout arrange logic.  We'll make this change for the next maintenance release.

That being said, what you're doing above might not work because Docking/MDI isn't expecting things like a Workspace to have its visibility changed externally.  I would not suggest doing that logic in a production application.  If you need to remove the Workspace, then pull it completely out of the visual tree instead.


Actipro Software Support

The latest build of this product (v21.1.0) was released 7 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.