1

This is the problem (unecessary margin showed by the red arrow):

enter image description here

This is the actual XAML of it:

<Ribbon DockPanel.Dock="Top">

This is the patch (which appears to me as working but a hack instead of a real solution):

<Ribbon DockPanel.Dock="Top" Margin="0, -22, 0, 0">

With the patch (more a hack than anything else to me):

enter image description here

Why there is a margin (border/space) at the top of the Ribbon and how to remove that margin properly without a hack (Margin -22 is a hack to me)?

Solution applied (Ed Bayiates solution):

<Ribbon DockPanel.Dock="Top" x:Name="MyRibbon" SizeChanged="RibbonSizeChanged">

private void RibbonSizeChanged(object sender, SizeChangedEventArgs e)
{
    ContentPresenter titlePanel = MyRibbon.Template.FindName("PART_TitleHost", MyRibbon) as ContentPresenter;
    if (titlePanel != null)
    {
        double titleHeight = titlePanel.ActualHeight;
        MyRibbon.Margin = new Thickness(MyRibbon.Margin.Left, -titleHeight, MyRibbon.Margin.Right, MyRibbon.Margin.Bottom);
    }
}
Eric Ouellet
  • 10,996
  • 11
  • 84
  • 119
  • Is that space for the Quick Access Toolbar? Have you used WPF Snoop to check? – Ed Bayiates Apr 22 '20 at 15:46
  • Not sure to know what you are talking about but I will try to check. Does Snoop is an external tool (with an icon of dog that smell shit??) or is the relatively new feature of Visual Studio on top of Window being debugged, or something else? – Eric Ouellet Apr 22 '20 at 15:59
  • I used the Live Visual Tree that comes with VS2019. The Ribbon has 2 children: "RibbonTab" and a "StackPanel". Both of them does not cover the region I want to remove (the unexpected margin). – Eric Ouellet Apr 22 '20 at 16:05
  • The dog icon one. You can highlight the area in question and see what part of the visual tree it is. From the Xaml in the MSDN article, I suspect it's the Quick Access Toolbar. You may need to explicitly set some 0x0 content for the QAT to collapse that area without the hack. – Ed Bayiates Apr 22 '20 at 16:14
  • It's the title bar panel. I think you are using a regular Window as a host instead of a RibbonWindow, which is why you are seeing the extra space. The hack is thus valid. I'm looking for a way to hide the title panel, but so far no success. Even setting it to collapsed still leaves space added due to a border without a template PART_ name. – Ed Bayiates Apr 22 '20 at 16:44
  • Nice thought applying it to size changed instead of loaded. – Ed Bayiates Apr 22 '20 at 17:17

1 Answers1

1

I think the area in question collapses into the Window titlebar if you host in a RibbonWindow instead of a standard Window.

If you can't do that, there are three items that take the same 22 pixel space in that area. One is PART_TitleHost. The second is a DockPanel with no Name attribute and the third is a Border with no Name attribute. Unless you re-template the whole Ribbon I don't think you can easily get rid of these. However, you could make your hack a bit less hacky if you set the y-margin to the exact size of this area. In the codebehind you can get the titlebar's actual height and reset the margin of the ribbonbar:

    private void MainWindow_Loaded(object sender, RoutedEventArgs e)
    {
        ContentPresenter titlePanel = Ribbon.Template.FindName("PART_TitleHost", Ribbon) as ContentPresenter;
        if (titlePanel != null)
        {
            double titleHeight = titlePanel.ActualHeight;
            Ribbon.Margin = new Thickness(Ribbon.Margin.Left, -titleHeight, Ribbon.Margin.Right, Ribbon.Margin.Bottom);
        }
    }

Image without that code:

enter image description here

Image with that code:

enter image description here

Ed Bayiates
  • 11,060
  • 4
  • 43
  • 62
  • 1
    Thanks a lot... It works great and it appears to me as a really better way to solve the problem. Note: I wrote in my question how I fix it (light modification). I wrote the code into a size changed event in order to stay coherent with any future changes (dynamic ones) in the sizing of the PART. – Eric Ouellet Apr 22 '20 at 17:20
  • Yes, that's a better adaptation of what I did, very nice :-) Now if the Windows styles change or the templated control changes, your app will still be correct. – Ed Bayiates Apr 22 '20 at 20:34