Wrong behaviour for docked out documentwindows

Docking/MDI for WPF Forum

Posted 9 years ago by Radu
Version: 9.2.0515
Avatar
Hello

We are having an application that uses a (generic) Ribbon on main window and two documentwindows (let's call them Doc1 and Doc2).
In a multimonitor scenario I take one of the documentwindows (Doc2) out and place it on my second monitor.
This Doc2 has now the keyboard focus.
If I click now directly on a button inside the ribbon (to paste some text or to add an item) then the main window gets active and also the Doc1... that means my text/item gets inserted inside Doc1 and not iside my (supposedly active) Doc2.

I've just checked how VisualStudio 2010 is behaving in this scenario and there it works as expected: the Doc2 remains active when I click buttons in the main window's toolbar and text gets inserted in the right place.

Any ideas how to overcome this problem?

Thanks in advance

Regards
Radu

Comments (3)

Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Radu,

Our Ribbon is set up to work the same as the standard WPF Menu/ToolBar do. Namely when you click a ribbon button, the button takes focus (and does need focus to know when to close popups, etc.) and then restores focus when clicked via Keyboard.Focus(null).

The problem in your scenario is that Keyboard.Focus(null) restores focus to the same Window but to a place outside the focus scope (menu/toolbar/ribbon). It will never put focus back into another Window, which is effectively what a rafted docking window is. We don't have any control over that either.

Offhand the only idea I have is to see if it's possible to track the previously-focused element as focus enters the Ribbon or one of its child controls. Then try and restore to that instead of doing Keyboard.Focus(null) later.

The downside to that approach is that if you are using routed commands, they may not function correctly since they may target the last focused element in the main Window instead of in your document window. Using other custom commands (perhaps some in other app frameworks that implement ICommand) may work around that issue.

Do you have any other ideas?


Actipro Software Support

Posted 9 years ago by Radu
Avatar
Hello

"...if it's possible to track the previously-focused element as focus enters the Ribbon or one of its child controls. Then try and restore to that instead of doing Keyboard.Focus(null) later..."

Isn't this something you should handle? I assume you know which windows lost focus when you got the focus inside the ribbon. And at the end instead of letting the focus go to some docwindow inside the main window you just steer it back to the window that lost it (very loose written but just as an idea)

Honestly I think the feature that allows documentwindows to be floating is unusable if I want more than just looking at its content. As soon as I click something in the ribbon the current docwindow being lost makes this feature unusable.
Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Right now Ribbon functions the same as the WPF ToolBar, etc. do. We will add a TODO item to look into adding this sort of functionality as an option, and will mark down your focus post with that item.


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.