Execute routing commands by specifying a floating document as CommandTarget

Hello,

Just for clarification, are you using our older Ribbon product's ribbon control or the newer Bars product's ribbon control?

Routed commands in WPF are all based on the control that has focus.  In WPF when you click on a control in the main Window, in your case a button in the Ribbon, the main Window is activated and core Microsoft WPF logic focuses the last control that was focused in that Window.  That is why you see the button's command get executed on the docked document, which now contains focus, instead of the floating document, which previously contained focus.

This StackOverflow article talks about the exact issue, as it is something that any WPF docking window system would run into.

We don't have a sample yet that illustrates a tested workaround for this, but we should work on adding one.

Thanks for the reply.

We are using ActiproSoftware.Controls.WPF.Ribbon version 24.1.1.

We understood that this is a WPF standard focus specification and is not currently supported.

We hope that samples will be provided in the future, or that functionality will be provided as a product.

Hello,

We've done some work the past couple days to update WindowChrome to add a feature where it can prevent clicks on ribbons and toolbars from activating the Window (and moving focus).  We've also updated our Bars Ribbon/StandaloneToolBar and older legacy Ribbon products to support the update in combination with using WPF's HwndSource.DefaultAcquireHwndFocusInMenuMode and Keyboard.DefaultRestoreFocusMode properties.

In addition, we've added a sample in the Docking/MDI area for the next build that shows how to integrate the Bars Ribbon and StandaloneToolBar controls with Docking/MDI so that buttons on the main Window toolbars can work on floating docking windows.

The same concepts could be used on the legacy (non-Bars) Ribbon, but the new WindowChrome.CanMouseActivateOverToolBar property  coming in the next build would need to be set a different way than in the new sample.  The legacy Ribbon requires you to programmatically get the existing WindowChrome instance from ribbon:RibbonWindow in code-behind and then set the property in C# code.  Documentation on this concept is here.

Hello.

When is the next build (probably version 24.1.3) scheduled to be available?
Or we could only find version 24.1.2, is that feature already available to us?

Hello,

Correct, the updated logic and new sample will be in v24.1.3.  We don't have a target release date yet since v24.1.2 just came out a little over a week ago and we will need to collect more updates before doing another release.  If you write us at our support address in a few days, perhaps we can build and push a prerelease package to nuget.org for you with the code updates.