Problem

Switching active toolwindow from auto-hidden one results in previous window activating

Posted 11 months ago by Avatar Chien A.

Don't know if this is a regression, but we've just noticed a bug that really limits the practicality of auto-hidden toolwindows.

Using the simple ide docking sample:


1. Move 'Document Outline' toolwindow (tw) to be docked on left side and auto-hide it
2. Click/activate 'Output' tw
3. Click on 'Document Outline' tw to activate/show it
4. Click on 'Find & Replace' toolwindow to activate/show it (Note: doesn't need to be auto-hidden, any tw other than 'output' will suffice)
5. Finally Click on 'Output' tw again and view output in it

Doing the above, notice that between steps 3 and 4, the 'Output' tw temporarily became activated again.

This extra activation did not happen in your WinForms version, and breaks a basic dockable window ability to bind a different toolwindow to selected content in an autohidden window. E.g. in Visual Studio you wouldn't be able to use the 'Properties' tw to view or edit the selected node in 'Solution Explorer' if it was auto-hidden, if a document Window etc became active in between changing active window from 'Solution Explorer' to 'Properties' since that would cause 'Properties' tw to bind to the document instead.

[Modified 11 months ago]


Comments (5)

Posted 11 months ago by Actipro Software Support - Cleveland, OH, USA

Hi Chien,

I'm trying this in build 664 and am not seeing what you describe occur.  Are you seeing the Output tool window's list showing that Output because active in between steps 3 and 4?


Actipro Software Support
Posted 11 months ago by Chien A.

> Are you seeing the Output tool window's list showing that Output because active in between steps 3 and 4?

Correct.

My Simple IDE sample had been modified with the change specified in original post of: http://www.actiprosoftware.com/community/thread/23925/focus-bugs-with-interopwindowsformshost-some, however given the scenario doesn't invovle any interaction with the extra toolwindow (bottom auto-hidden and hosting winforms content) that adds, I did not think it was relevant.

Turns out it is somehow relevant - we are on 663 (664 doesn't look like it has anything relevant in it) and when I did a fresh install, indeed there is no problem, however once modified again with above code, the scenario I originally described occurs.

The WIndowActivated ouput I see after those steps is:

WindowActivated: Title=Ouptut

WindowActivated: Title=Document Outline - About.txt

WindowActivated: Title=Ouptut

WindowActivated: Title=Find & Replace

WindowActivated: Title=Ouptut

Edit: Perhaps to do with disabling UseHostedPopups due to WinForms?

[Modified 11 months ago]

Posted 11 months ago by Actipro Software Support - Cleveland, OH, USA

Hello,

Yes that would do it.  The "UseHostedPopups = false" feature allows interop controls to appear properly in auto-hide flyouts.  We accomplish that by using a separate WPF Window to display them.  When you click the Find/Replace tab, you are first activating the main WPF Window (that contains the DockSite) from the WPF Window that hosts the auto-hide flyout.  WPF sees that activation and restores focus to the last control in the WPF Window that was focused, in this case the Output box.  We don't have control over that.  Then your tab click triggers the WPF Window for the auto-hide flyout to show again.

I'm not sure what to tell you here since it's all due to how core WPF moves focus between WPF Windows upon activation.  All we are told is that focus entered the Output tool window, so we flag it as activated.  We don't know if it was triggered by a click, Window activation, programmatically by you, etc.  I suspect even if you didn't have interop controls and had "UseHostedPopups = true", you'd still run into the same situation with floating tool windows, which are of course in their own WPF Window.


Actipro Software Support
Posted 11 months ago by Chien A.

This is a pretty critical flaw with non-UseHostedPopups mode.

Autohidden windows are a big part of the dockable window UI design, and this potentially renders the autohide state unusable if even a single toolwindow contains WinForms content.

Technical difficulties aside, a fundamental problem with current behaviour is how despite the auto-hidden toolwindow being activated/focused, from what you describe, logical focus within the DockSite remains on the last previously focused docked/tabbed toolwindow. This doesn't make sense, and in combination with the whole separate WPF window approach, is what is causing the problematic extra WindowActivated events.

While not a perfect solution, it would be far better if the tab of the auto-hidden toolwindow is given logical focus within the DockSite when its auto hide popout opens (e.g. temporarily change FrameworkElement.Focusable to true), or if this is problematic somehow, even a hidden control would probably suffice.

This would prevent the problem WindowActivated events from happening if the DockHost Window becomes focused for whatever reason - the currently active autohide tab will regain focus instead, and anytime an auto-hide tab becomes focused, it should auto-transfer focus to its toolwindow, which should remain popped out, and the DockSite.ActiveWindow (just like when UseHostedPopups = True).

[Modified 11 months ago]

Posted 11 months ago by Actipro Software Support - Cleveland, OH, USA

Hi Chien,

That's a good idea, focusing the auto-hide tab item.  We've tested that out and it resolves the issue in our demo when "UseHostedPopups = false".  Further, it appears VS also focuses the tab when clicking on it.

If you'd like to try a preview build with the update, please write our support address and mention this thread.


Actipro Software Support
Information The latest build of this product (2018.1 build 0674) was released 4 days ago, which was after the last post in this thread.

Add a Comment

Please log in to a validated account to post comments.