Logical focus scopes within tool windows cause activation/deactivation issues

Docking/MDI for WPF Forum

Posted 7 years ago by Brian Collins
Version: 12.1.0560
Platform: Silverlight Controls
Environment: Windows 7 (64-bit)
Avatar

Logical focus scopes do not work properly within dock sites. In the following sample, clicking on Button2 within ToolWindow2 causes ToolWindow2 to be deactivated and ToolWindow1 to be activated. Clicking on Button1 within ToolWindow1 does not cause this problem. I can "fix" the issue by removing the focus scope in ToolWindow2, but focus scopes should be compatible with dock sites. This seems to be a bug.

<docking:DockSite>
	<docking:SplitContainer>
		<docking:ToolWindowContainer>
			<docking:ToolWindow Title="ToolWindow1">
				<Button Content="Button1" />
			</docking:ToolWindow>
		</docking:ToolWindowContainer>
		<docking:ToolWindowContainer>
			<docking:ToolWindow Title="ToolWindow2">
				<Border	FocusManager.IsFocusScope="True">
					<Button Content="Button2" />
				</Border>
			</docking:ToolWindow>
		</docking:ToolWindowContainer>
	</docking:SplitContainer>
</docking:DockSite>

Comments (3)

Answer - Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Brian,

Sorry but focus and focus scopes are managed internally by WPF and aren't really anything we have control over.


Actipro Software Support

Posted 7 years ago by Brian Collins
Avatar

I only expected that focus scopes would work the same way within tool windows as they do everywhere else in WPF. This problem took me a while to track down because it wasn't obvious to me that I couldn't use focus scopes within tool windows.

If you do not plan to fix your bug, why don't you add a note to your documentation that "Using FocusManager.IsFocusScope='True' within a DockSite can cause unpredictable results and is not recommended. Actipro is unable to prevent arbitrary windows that you are not interacting with from stealing the activation of the window that you are interacting with, if the window you are interacting with contains a focus scope".

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Brian,

Sorry I should clarify a bit more.  If your intention here is to make a toolbar sort of thing, then it may be ok to include a focus scope as long as you have some sort of focusable control containing it.  So perhaps if you had a Border with Focusable="True" above this Border, WPF may choose to keep focus within the tool window, although you'd have to test it to be sure.

The way WPF handles focus scopes is that after a button in a focus scope is clicked, it attempts to return focus to the main focus scope within the same parent Window-based object.  Our tool windows don't inherit Window and are just regular Control-based objects.  Anyhow if you have a focusable container control around the "toolbar" area that has the focus scope, WPF may focus that focusable container instead of moving it to another control in the root Window, which was in your case the other ToolWindow1's content.  But it also might not do so unless some other control outside the focus scope previously had focus in ToolWindow2.  Meaning you might need something like a TextBox in ToolWindow2 to have focus before clicking the toolbar area in order for focus to remain in that tool window post-click.


Actipro Software Support

The latest build of this product (v2018.1 build 0675) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.