Restore floating fallback for incompatible dock groups#1072
Conversation
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4d67eaf5d7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (!executed | ||
| && _context.DragDockable is { } dockable | ||
| && DockCapabilityResolver.IsEnabled( | ||
| dockable, | ||
| DockCapability.Float, | ||
| DockCapabilityResolver.ResolveOperationDock(dockable)) | ||
| && _hostWindow.Window?.Factory is { } factory) | ||
| { | ||
| dockable.SetPointerScreenPosition(screenPoint.X, screenPoint.Y); | ||
| factory.FloatDockable(dockable); |
There was a problem hiding this comment.
Avoid floating managed docs on failed drag drops
When a managed host-window drag ends without a valid dock target (executed remains false), this new fallback calls factory.FloatDockable(dockable) on _context.DragDockable, which is resolved as a ManagedDockWindowDocument. In this codebase, FactoryBase.FloatDockable removes the dockable and depends on CreateWindowFrom to recreate it, but CreateWindowFrom has no ManagedDockWindowDocument case (see src/Dock.Model/FactoryBase.cs switch around lines 632-748), so the dockable can be removed from ManagedWindowDock and disappear after an invalid drop instead of simply staying where it was dragged.
Useful? React with 👍 / 👎.
Summary
Testing