Fix Floating Window Closing Behavior and Visibility Handling

[xoma-zver]

This pull request addresses several issues related to closing floating windows (LayoutAnchorableFloatingWindowControl and LayoutDocumentFloatingWindowControl) using standard Windows mechanisms (Taskbar 'X' button, Alt+F4) and improves visibility handling for floating document windows.

Related issues this might solve:
#368

Bugs Fixed:

1. Incorrect Closing Logic via OS Commands (Alt+F4, Taskbar 'X'): The previous implementation had flaws in handling standard OS close commands for floating windows:
   • Floating document windows (LayoutDocumentFloatingWindowControl) could potentially bypass parts of the standard AvalonDock closing validation and execution logic when closed via OS commands.
   • Floating anchorable windows (LayoutAnchorableFloatingWindowControl) lacked specific handling for OS close commands, potentially leading to the window being destroyed directly by the OS, bypassing AvalonDock's hide/close logic entirely.
   • In both cases, custom CloseCommand or HideCommand overrides (e.g., set via styles) could be ignored when closing through OS mechanisms.
2. Floating Document Window Visibility: LayoutDocumentFloatingWindowControl lacked the mechanism to automatically hide its WPF window view when its underlying model became effectively invisible (e.g., all contained anchorables were hidden). Conversely, it couldn't automatically reappear when the model became visible again. This resulted in empty floating windows remaining visible after closing via the taskbar 'X' if they contained only hidden anchorables.
3. Incorrect Visibility Calculation: LayoutDocumentPaneGroup.GetVisibility() always returned true, preventing the correct propagation of visibility changes up the layout tree, which contributed to the floating document window visibility issue.

Summary of Changes:

• Refactored OnClosing Methods: The OnClosing overrides in both LayoutAnchorableFloatingWindowControl and LayoutDocumentFloatingWindowControl have been substantially rewritten to serve as the single, reliable entry point for user-initiated window closing.
  • They now correctly distinguish between LayoutDocument and LayoutAnchorable children during validation and execution phases.
  • Proper validation logic is used, including checking CanClose/CanHide properties, internal TestCanClose/TestCanHide, specific manager events (DocumentClosing, AnchorableClosing, AnchorableHiding via new helper methods), and command CanExecute.
  • The appropriate action (close or hide) is executed for each content type, respecting custom commands (CloseCommand/HideCommand) first, then falling back to default internal logic, and finally raising the correct corresponding manager events (DocumentClosed, AnchorableClosed, AnchorableHidden).
  • The closing of the WPF Window itself (e.Cancel = true) is now correctly cancelled only if at least one child element was hidden and none were closed permanently, ensuring the floating container persists for hidden items.
• Added Visibility Handling to LayoutDocumentFloatingWindowControl: Implemented EnableBindings/DisableBindings and added event handlers (_model_IsVisibleChanged, Model_PropertyChanged for IsVisible), mirroring LayoutAnchorableFloatingWindowControl. This ensures the window's Visibility now correctly synchronizes with its model's IsVisible state, allowing it to hide and reappear automatically.
• Corrected LayoutDocumentPaneGroup.GetVisibility(): Fixed the method to return true only when it contains visible children, enabling correct visibility updates in the layout hierarchy.
• Cleanup: Removed redundant WM_CLOSE handling.

[john-lemon7]

Your fix does correctly resolve the issue and close the float window correctly.
However, it seems to introduce new problems:
After moving all documents to a floating window, they can no longer be dragged back to the main window.
The application now crashes frequently after applying this fix.
All of these problems can be reliably reproduced using TestApp

[sharpSteff]

That PR is way to big to allow a proper review in detailed

[sharpSteff]

@xoma-zver Thanks for the PR, but I can not merge anything, which might fix an issue.

[xoma-zver]

@sharpSteff, Is there anything I can do to help with this?

[sharpSteff]

it would be great, if we can split that PR into multiple ones