I've noticed that the autohide behavior is different between the Win and WPF versions of the Dock Manager. In the WinForms version, if I click on a control outside of an unpinned content pane, the content pane will autohide (fly in). This does not seem to be the case in the WPF version. If I have a Content Pane that has focus, but is unpinned, if I click on a control outside of the content pane, it will not auto hide. In fact, I can't seem to make it auto hide unless I toggle on the pin of the content pane. Is there any way for me to change the auto hide behavior of the WPF XamDockManager to work the same way as the UltraWinDock version?
Actually in both cases if the unpinned pane is active (i.e. it has the input focus) then clicking somewhere else in the application would not necessarily cause the flyout to close. That would only happen if you gave focus to something else. I suspect that in the winforms case you were clicking on a control that took focus (e.g. usercontrol, textbox, etc.) but in this case you're not clicking on something that takes the keyboard focus. If it is taking the keyboard focus and still not closing then please submit a sample that demonstrates the issue and we can look into it further.
Actually in both cases, I clicked on a control outside of the content pane which indeed did take focus to another control. However in the WPF version, the content pane did not fly back in (hide) when I clicked on the control outside -- that is the difference. Are you saying that the WPF version should fly back in as well? We have a mix of WinForms and WPF in our application, with the WPF code hosted inside of WinForms and perhaps that is my problem?
What I'm saying is that if the unpinned tab was the active pane and you clicked into another pane and that became the active pane (whether that contains wpf elements or an hwndhost like windowsformshost) or you clicked into another wpf element outside the xamdockmanager that the flyout should flyin because the flyout only stays open while the pane is active or while the mouse is over the unpinned tab/flyout. If your clicking into a WindowsFormsHost control outside the xamDockManager then it could well be that the xamDockManager wouldn't know about that. Can you post a small sample that demonstrates the issue?
Maybe your doing something within your control to cause it to close up?
Thanks for your explanation. In our application using UltraDockManager, the unpinned panels do indeed hide automatically when the mouse leaves the panel (without clicking on any other control). I looked briefly to see if there were any special settings, etc, to make that happen but I didn't see any. I'm actually quite startled by this revelation, as I ran several of the Infragistics Winform samples that has a dock, and the autohide behavior does work as you described. So I'm puzzled why ours behave differently. In any case, that's how our application has worked for several years and our customers are used to that behavior.
So again just to be clear, the winforms UltraDockManager works very similar to VS and so does xamDockManager. In both cases when a pane is active (i.e. it has keyboard focus) - which would happen when you click on the unpinned tab or otherwise activated it - the flyout will not close until the focus goes elsewhere. There are some exceptions - e.g. in VS and xamDockManager the flyout will close if you hover over another unpinned tab - but that is generally how it works when active. For UltraDockManager/XamDockManager/VS when you hover over the tab item, the flyout will be displayed but the pane will not be made active. When the flyout is shown for an inactive pane, it will remain visible/flown out as long as the mouse is over either the tab item representing the unpinned pane or the mouse is over the flyout itself. This is how UltraDockManager and XamDockManager (and VS) work.
BTW with regards to your specific question about mouse leave you can look at this post.
Thanks for all of your help on this, Andrew. Here's another thought -- what if I tried catching the mouse leave event on the panel, and explicitly force it to hide if it is unpinned? Would this be a reasonable solution? This seems to be how the WinForms dock panels work, and that's ideally what I would like to happen. The difference would be that in the WinForms case, there is a slight delay between the time the mouse leaves the panel and when it hides. I could add a timer but that may be complicated... I could probably live without the time delay.
No, tree map probably doesn't take keyboard focus because it doesn't utilize focus. You could try putting it inside an element that would take focus - e.g. a scrollviewer - but if you do that you might want to set its Horizontal and VerticalScrollbarVisibility to Disabled.
Now the fact that you've got interop will make this more complicated. The scenarios I mentioned though would work - i.e. where keyboard focus went to a different WPF element (or to null and keyboard focus wasn't within an hwndhost within that pane) - in WPF the keyboard focus would go to null if focus went to another hwndhost. The only other would be to explicitly cause it to flyin (e.g. getting the unpinned pane - from the CurrentFlyoutPane property - and calling ExecuteCommand on it with the ContentPaneCommands.FlyIn. It would retain keyboard focus though and still be the active pane.
Tools in a toolbar like ultratoolbarsmanager do not take keyboard focus so that wouldn't cause the flyout to close up - it wouldn't in VS either.
If you find that keyboard focus is going elsewhere and the flyout is not closing then please provide a sample and we can look into that.