Annoyance with AutoHide Windows

Docking/MDI for WPF Forum

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?


[Modified at 09/10/2008 06:00 PM]

Comments (3)

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA
Hi Mike,

Are you able to make a set of repro steps in our Features demo that shows this happening? We've been trying but have been unable thus far. The steps you describe get to be fairly complex so if you have a few minutes can you make a simple sample project that repros this, email it over, and we can debug it?

Thanks for your help, it does sound like this scenario is causing incorrect behavior.

Actipro Software Support

Posted 16 years ago by Mike Strobel - New York, NY
Hi Bill,

If you compile and run the Prism quickstart I sent you with the DockSiteRegionAdapter, you should be able to reproduce this scenario very easily:
  1. Run the UIComposition project.
  2. Click the "pin" to auto-hide the "Employees" tool window.
  3. Hover over the "Employees" tab to expose the hidden window.
  4. Click on either of the two employees listed.
  5. Click on any of the items in the "Views" or "Active Views" ListViews to the left of the DockSite.
  6. Observe the Active View to be the "Employees" tool window, which has since lost focus and been hidden away.
I believe the key to this reproduction is that the "Employees" tool window loses focus to an element outside of the DockSite. Hitting the Escape key or clicking anywhere inside of the DockSite should produce the correct behavior and update the ActiveWindow property. Clicking outside of the DockSite in this case does not update the ActiveWindow.

FYI, I have checked to see how the Visual Studio docking system handles this behavior, and in VS2008 focus is transferred back to the active document as soon as a selected auto-hide tool window is hidden away (it does not wait for another window to receive focus). I think this would be the most intuitive behavior.


[Modified at 09/15/2008 11:11 AM]
Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA
Great, we'll check that out. Thanks Mike!

Actipro Software Support

The latest build of this product (v24.1.2) was released 28 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.