Not logged in▾
Log In Register
Forgot Password Resend Validation E-mail

LastActiveDocument property changes when clicking in ribbon

Docking/MDI for WPF Forum

Posted 14 years ago by Craig - Varigence, Inc.
Version: 11.1.0542
Platform: .NET 4.0
Environment: Windows 7 (32-bit)
Avatar
I have an application that uses the DockSite's LastActiveDocument property for some behaviors. Generally, it works great since as the user clicks between document, the LastActiveDocument property indicates the last clicked on document (since it's the last actived) as would be expected.

However, I hit a scenario where I moved one of my documents outside the application, so it's floating. I then click a couple times back and forth between my floating document and the docked document window. I then click on the floating document once more, and then click on the ribbon. Unexpectedly, the LastActiveDocument property changes from my floating document to the docked document, despite me never having clicked on the docked document.

I consider this a bug since I didn't intend to change anything regarding my document's active status. The floating document should still be active; I just want to use the ribbon.

I'm sending along a sample project with embeeded repro steps to illustrate this and possibly make the issue clearer.

Thanks,

-Craig

Comments (8)

Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Craig,

This is a generally known issue with WPF. When you click the Ribbon, you are activating the Window that it is contained in. The Window will then restore focus to it's last focused element.

Microsoft added a workaround for this in .NET 4, which is described here. But basically, you'd need to add this to your App class: 
static App() {
    HwndSource.DefaultAcquireHwndFocusInMenuMode = false;
    Keyboard.DefaultRestoreFocusMode = RestoreFocusMode.None;
}

Actipro Software Support

Posted 14 years ago by Craig - Varigence, Inc.
Avatar
The code snippet you provided works great, thanks.
Posted 12 years ago by Andras Eles
Avatar

I am using 2012.2 build 0570 and originally experienced the same issue with floating documents as Craig. 

The solution suggested here solves the problem for me too but has an unfortunate side-effect. All the controls I have on the ribbon and bound to a command from the ApplicationCommands class get disabled as soon as I click on a control in the ribbon.

Has anybody experienced this before? Do you have any suggestion to solve it?

thanks,

andras

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

Hi Andras,

RoutedCommands all track enabled state based on where focus is within the current Window that also contains the ribbon/toolbar.  If you are having trouble with them, you might try moving over to something more like a delegate command.  A lot of UI frameworks like Prism, etc. utilize those instead of routed commands.  You can also google to find a lot of sample online for building a delegate command.

Actipro Software Support

Posted 12 years ago by Andras Eles
Avatar

Thanks for the quick reply.

Though I am familiar with delegate commands I am hesitant to move over to using them in this particular case. The reason is that we are building an extensible application. Some of our plug-in components are used in other host applications as well. So far implementing e.g. the Undo behavior is common (creating a command binding for ApplicationCommands.Undo) regardless the actual host application. If I follow your suggestion the components have to implement a specific solution for each host application.

Meanwhile I have found this post that gave me some guidance on how to interact with the ribbon while keeping the focus on a floating window. Unfortunately this solution also has a side effect; it breaks the keyboard navigation of the ribbon.

Now I wonder if I could hijack the tracking logic of RoutedCommands and could direct them to a floating window instead of the window that has the ribbon?

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

Hi Andras,

I'm not sure... the closest thing we've seen is where customers have wired up the routed command handlers on all the rafting windows that we create (overriding DockSite.CreateRaftingWindow, calling the base method, and adding command handlers to the result).  Then set up those handlers to forward to the "real" handlers on the main window.

Actipro Software Support

Posted 12 years ago by Andras Eles
Avatar

After a couple of weeks of interruption I took another look at this issue. What I see now is that whenever I press the ALT key (or F10) while a document is docked into the application's Main Window the keyboard focus is moved to the Ribbon and the Key Tips are displayed.

However pressing the ALT key (or F10) has no such effect when the document is floating.

I have tested the behavior with the "RibbonWindow with Docking" sample via the Sample Browser and found the same. Documents are not allowed to float in this sample application but as soon as I float a ToolWindow pressing the ALT key has no visible effect.

Is there something we have to do in order to activate the Ribbon when those system keys are pressed on a floating window? 

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

Hi Andras,

Unfortunately that's an aspect of WPF.  Basically key strokes only get handled within the Window that contains them.  In the case of floating documents, those are hosted by a different Window behind the scenes so things like the Alt key, etc. aren't tracked there.

Although we haven't tried, you may be able to somehow forward the rafting Window's PreviewKeyDown event over to the main Window.  Perhaps Ribbon would pick it up then.  You'd probably need to do the same for the PreviewKeyUp event.

Actipro Software Support

The latest build of this product (v24.1.5) 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.