DockMvvmSample shows drag/drop and refresh failures.

[cliffowen]

I am using VS 2026, all dependencies updated to latest versions like CommunityToolkit.mmvm 8.4. Avalonia.Desktop 11.3.11 (and related 11.3.11 libs), etc.
Clone a clean project.
Load the solution into VS2026 and build.

I want to make a Mvvm sample.. start with DockMvvmSample.

The sample works, more or less, except the windows in the upper right. Tool 5 and Tool 6 do not repaint properly. If you drag them elsewhere, they can go but you can only drag 1 of them. Any other window that behaves properly will stop behaving properly if you drag it to the upper right.

Once there is only 1 window in the upper right, whatever it is you cannot drag it away. It's stuck. It won't repaint properly, won't respond to the drag.

Go to the windows on the left. Drag all of them away. Notice that you cannot drag the last one away. In my case it was Tool4 that got left behind. Can Close, Can Float, Can Pin, Can Drag, Can Drop are set. You can not drop onto tool 4. You cannot get anywhere near the dock left button because it disappears. That area is now dead space.

Close Tool 4. Now try to drag anything and dock to the left of the document area. You cannot dock anything to the left of the document area at all.

[curin]

I'd like to echo this, but I had even more inconsistent behavior with the mvvm samples (both normal and code only).
If the tools were hidden when I went to drag them they duplicated themselves, but the duplicate and the original did close together and have other odd behaviors.
When I dragged tool1 to dock on the side of tool 5, tool 1 and tool 5 both lost their docking controls.

[MarkL1213]

One thing I noticed in the DockMvvmSample DockFactory.cs is that the ToolDock in the upper right (tools 5 & 6) has the GripMode set to GripMode.Hidden. This appears to control the appearance of the tool's title bar. If you drag tool 5 or 6 off to floating, they seem to end up docked/floating and the newly create floating dock inherits this hidden grip state. This makes the new window unmovable/undockable as you can't grab the contents.

Contrast this with the lower right ToolDock (tools 7 & 8) which has GripMode.AutoHide, which keeps the title bar hidden until you mouse over it. Floating either of these gives you a title bar you can drag and redock with.

The behavior is interesting if you drag to float tool 5, creating a hidden grip floating dock. Then drag a different tool and dock in the center compass. Now you see tabs that allow one of the tools to be dragged and redocked. If there is only one tool in a hidden grip dock you get no tabs and no title bar.

Doing the same thing but instead of docking in the center compass, dock to the left/right/top/bottom dock and a new ToolDock in created in the floating window (again inheriting it's parent dock properties). This gives you a decorated floating tool window state.

Long story short, I think a lot of what you are seeing is intended behavior. Each of the four ToolDocks are configured differently to showcase these differences. These properties are not exposed in the sample UI, only tool properties are shown. Take a look at the DockFactory.CreateLayout() function, this is where the magic happens.