How to customize the floating DockHost?

Hello,

We're glad to hear you're enjoying our Avalonia controls!

I'll explain the process of what happens behind the scenes when a docking window is floated so we're on the same page. The main Window has a DockSite that you create and initialize options on. The DockSite's control template has a DockHost control inside of it, meaning the DockSite itself effectively has an implicitly-created DockHost. When a docking window is floated, a second host Window is created to contain everything that is floated. A new DockHost is placed as a child in that Window's Content. This means that there is only ever a single main DockSite, and one to many DockHosts. The DockHost is what actually contains the UI for things like auto-hide tab strips and is the root of all docking window hierarchies or a Workspace.

I suspect the reason you would like to have a Ribbon on the floating Window is that when you have a floating document, if you click the Ribbon in the main Window, the Avalonia UI framework (likely listening to a Win32 event in Windows) moves focus back to the last control in the main Window that had focus, which could be inside another document window that hasn't been floated. And then your context is changed. Is that correct?

When we create a new Window to host any docking window that is floating, the protected virtual DockSite.InitializeFloatingWindow method is called and the Window instance is passed. It should have a DockHost set as its Window.Content. You could possibly override that method and get the DockHost instance currently in Window.Content.  Then create a root Panel and put your Ribbon or other UI in that, along with the DockHost instance.  Set that root Panel as the new Window.Content.  Does that work?

Hi,
Thank you for in detail explanation.
I will follow your suggestion and let you know if it works to me.

BTW: The reason why I would like to have a Ribbon on the floating Window is just a request from product management:
"Each floating window shall have its own contextualized Ribbon". The content of a ribbon shall depend on active tab.

OK. I played araound a bit and I am stacked on the following problem:
To reach the DockSite.InitializeFloatingWindow method, I have to subclass the DockSite. right?

So I created following class:

public sealed class MainDockSite : DockSite
{
    public MainDockSite() : base()
    {
    }
 
    protected override void InitializeFloatingWindow(Window window)
        => base.InitializeFloatingWindow(window);
}

Now I have to put it into Xaml.
I replaced actipro:DockSite with mainViews:MainDockSite:

      <mainViews:MainDockSite x:Name="MyMainDockSite"
                  DocumentItemsSource="{Binding Documents.DocumentItems}"
                  DocumentItemContainerTheme="{StaticResource DocumentWindowTheme}">

it should be ok....
but after this change, my docked tools and documents do not display anylonger...
What am I missing?

The most likely cause is the implicit DockSite style not being applied.  In Avalonia, the default behavior of each control is to use the control's type as the style key.  When you create a derived control, that effectively changes the default style key from our DockSite to your MainDockSite.  You should be able to resolve that be also overriding the StyleKeyOverride property to return DockSite as the type for the style key:

protected override Type StyleKeyOverride => typeof(DockSite);

FYI
this did not help:

protected override Type StyleKeyOverride => base.StyleKeyOverride;

but this one does: 

protected override Type StyleKeyOverride => typeof(DockSite);

Thanks!

Now I can continue with customization of DockSite.

I will let you kow how it is going.

I succeeded to inject a border around the DockSite.
Hopefully I will succeed to create a Ribbon as well :)
If I will need your further assistance, I will let you know, otherwise I will close the topic.

Thanks for the great support!

Excellent, and sorry for the partially incorrect solution.  I confused our WPF-based solution (which explicitly uses the DockSite type) with the Avalonia-based solution that uses GetType() method.  As you clearly saw, the GetType() method always returns the current type even when called by the base class.  Glad to hear the other suggestion was all you needed.

I'm going to edit the original post to avoid confusing anyone who may read this in the future.

not a problem. I've learnt a lot from our conversation.
thanks!