"Float All" command misbehaves when at least one document has "CanFloat = false"

Hello,

Thanks for reaching out.  I tried testing this scenario in our Docking/MDI's Simple IDE demo, but was unable to reproduce it.  In my test, I took these steps:

1) Set one of the document windows to have CanFloat = false.

2) Ran the demo, right clicked on a document tab, and picked the Float All menu item.

3) All documents floated except the one that had CanFloat = false set, as expected.

In my testing, no documents became inaccessible.

Since your original post mentioned you’re on v25.2.3, could you let us know the exact steps needed to reproduce the problem in the Simple IDE demo for that version? That will help us pinpoint what might be different in your scenario.

indeed. your scenario works by me as well.
Try this one:

• create docA (CanFloat= false)
• create doc1 (CanFloat= true)
• create doc2 (CanFloat= true)
• create doc3 (CanFloat= true)
• note that the documents are presented in reverted order: doc3, doc2, doc1, docA
• call FloatAll -> all doc1-3 are now undocked together in a separate cantainer. fine!
• dock the container back to main window by drag&drop it
• call FloatAll again -> all doc1-3 disapear.

let me know if you can pin it.
best.

Now I noticed, that the menu command Float leads to the same buggy behaviour.

Another scenario:

• undock a doc1 document by drag & drop it out of the container
• dock it back by drag & droping it
• call Float of FloatAll -> Bug (doc1 disapears)

Sorry, I could not find where I can set CanFloat= false in your 'Docking/MDI', so test above refer to my App.

Unfortunately, we're still not able to reproduce.  The currently released Sample Browser does not include an option to toggle if a document can float, but it is easy to add (and will be included in the next release).  There is a "Document Properties" tool window used by the Simple IDE sample which shows some basic properties for the selected document, and you can add a checkbox that binds to the document's CanFloat property.

Update the DocumentPropertiesToolWindow.axaml file and add the following after the "Is read-only" checkbox:

<CheckBox IsChecked="{Binding CanFloat}" Content="Can float" />

With that option, the "null" state means the global "Can Float" options are used (which is the default), so you can clear the checkbox to indicate that the selected document cannot float.

With that change, please try to reproduce in our sample app and provide steps to reproduce.  If you cannot reproduce in our sample app, please create a simple sample application that demonstrates the issue and send to our support email address with a reference to this forum post.  Before zipping your source, be sure to remove any bin/obj folders so the attachment is not blocked.

As a side note, double-check that the floating document windows have really disappeared and aren't just hiding behind the main application window.

I see..... 
this of course questions whether the issue is on your dide or on mine. :(
I will investigate it. Thanks for help.

Hi,

Finally, I created a snippet app that let you reproduce the issue.
I created a ticket, number 2EC-317E2431-0001. where I uploaded the code and the video.

Could you please help me to locate the issue?

Thank you for providing the sample, and we were able to identify the issue.

In your sample, you are modifying the control hierarchy to inject a RibbonContainerPanel as the parent of the floating DockHost.  As you noted, this works fine the first time you float the window, but then subsequent attempts to dock and re-float result in the documents disappearing.

The root cause of the window not showing is that there is a specific heirarchy expected for the floating controls.  The altered DockHost parent visual caused the control logic to believe the floating DockHost was already properly parented in a floating window, but it was not.  That's why the DockHost never appeared, as expected, in a new floating window.

The recommended way to add a RibbonContainerPanel into the hierarchy is to re-template the DockHost to include a RibbonContainerPanel as part of the ControlTemplate.  Then your logic to inject a Ribbon into the floating DockHost would simply find the RibbonContainerPanel visual child that was already in the template and add the desired Ribbon as a child.  Alternatively, you could also include the Ribbon in the template and just modify its configuration directly instead of injecting a control.

For convenience, Actipro Avalonia Pro customers can download all of our control styles/templates from their organization page on our site.  The download option is available in the blue Actions button listed next to the product.

thank you for your support!