Posted 16 years ago
by Mike Strobel
- New York, NY
I've been working on a DockSite region adapter for CompositeWPF (Prism), and I've discovered an edge case regarding the DockSite's ActiveWindow property and AutoHide windows. In short, it is possible for a DockSite's "ActiveWindow" to be an auto-hidden tool window (which has since lost focus), despite visual indicators suggesting that the currently selective document window is active. I've detailed the scenario below.
I have a DockSite with a TabbedMdiContainer. That DockSite represents a CompositeWPF region. I have developed a region adapter that keeps the region's views collection in sync with the DockSite's windows collection, and the region's active view in sync with the DockSite's active window.
I have a view hosted by a tool window that is docked on the left-hand side of the DockSite. I click the pin to auto-hide it.
I hover over the tab to expose the (now hidden) AutoHide tool window.
I click on a button in the AutoHide tool window, which in turn causes a new view to be added to the region.
The region adapter sees that a view has been added to the region; it cooks up a DocumentWindow to host the view and then opens it (without selecting it).
Now that the new view has been added to the region, the view is programmatically activated (the region's active view is set to the content of the DocumentWindow).
The region adapter sees that the region's active view has changed; it activates the DocumentWindow hosting the active view.
The DockSite's ActiveWindow property briefly changes to the new DocumentWindow.
The delayed effect of the mouse click causes the (still exposed) AutoHide window to be reactivated.
The region adapter handles the DockSite's WindowActivated event and sets the region's active view to the contents of the AutoHide tool window. The view hosted by the DocumentWindow is deactivated.
I click somewhere outside of the DockSite.
The AutoHide tool window loses focus and disappears.
Now... the DockSite's ActiveWindow property is still set to the (now hidden) AutoHide tool window. However, all visual indications suggest that the new document window is active (document tab is shown in bold, and no AutoHide popups are open). It seems unintuitive for the hidden AutoHide window to remain active at this stage. The bigger problem is that the region's active view is still set to the content of that hidden window. Thus, any commands that target the region's active view will either be disabled (because the view in the hidden window is not a valid target), or will operate on a view that the user perceives to have "gone away" rather than the view that appears to be selected.
Is the current behavior intentional? Can it be changed? If not, can some events be added to the DockSite or ToolWindow class to indicate that an AutoHide window has been shown or hidden?
Thanks,
Mike
[Modified at 09/10/2008 06:00 PM]
I have a DockSite with a TabbedMdiContainer. That DockSite represents a CompositeWPF region. I have developed a region adapter that keeps the region's views collection in sync with the DockSite's windows collection, and the region's active view in sync with the DockSite's active window.
I have a view hosted by a tool window that is docked on the left-hand side of the DockSite. I click the pin to auto-hide it.
I hover over the tab to expose the (now hidden) AutoHide tool window.
I click on a button in the AutoHide tool window, which in turn causes a new view to be added to the region.
The region adapter sees that a view has been added to the region; it cooks up a DocumentWindow to host the view and then opens it (without selecting it).
Now that the new view has been added to the region, the view is programmatically activated (the region's active view is set to the content of the DocumentWindow).
The region adapter sees that the region's active view has changed; it activates the DocumentWindow hosting the active view.
The DockSite's ActiveWindow property briefly changes to the new DocumentWindow.
The delayed effect of the mouse click causes the (still exposed) AutoHide window to be reactivated.
The region adapter handles the DockSite's WindowActivated event and sets the region's active view to the contents of the AutoHide tool window. The view hosted by the DocumentWindow is deactivated.
I click somewhere outside of the DockSite.
The AutoHide tool window loses focus and disappears.
Now... the DockSite's ActiveWindow property is still set to the (now hidden) AutoHide tool window. However, all visual indications suggest that the new document window is active (document tab is shown in bold, and no AutoHide popups are open). It seems unintuitive for the hidden AutoHide window to remain active at this stage. The bigger problem is that the region's active view is still set to the content of that hidden window. Thus, any commands that target the region's active view will either be disabled (because the view in the hidden window is not a valid target), or will operate on a view that the user perceives to have "gone away" rather than the view that appears to be selected.
Is the current behavior intentional? Can it be changed? If not, can some events be added to the DockSite or ToolWindow class to indicate that an AutoHide window has been shown or hidden?
Thanks,
Mike
[Modified at 09/10/2008 06:00 PM]
