Question

In Visual Studio 2010, Dockable Windows seem to work like expected in every situation.
If a “Floating” document is active and some menu is selected (e.g Edit -> Paste), then the “Floating” document still has Focus and the command will be executed against that “Floating” window. Also, notice how this is clearly visible in the UI. MainWindow.xaml is still active and the Main window in Visual Studio is inactive even though the Team-menu is selected.

I’ve been trying to get the same behavior using alot of different 3rd-party docking components but they all have the same problem: once I select the menu, the MainWindow is focused and my floating window does not have focus anymore. Does anyone know of a way to get the same behavior here as in Visual Studio?

At the moment I’m using Infragistics xamDockManager and the problem can be reproduced with the following sample code.

• Right click “Header 1” and select “Float”
• Click the “File” menu
• Notice how MainWindow receives focus.

xmlns:igDock=”http://infragistics.com/DockManager”

<DockPanel LastChildFill="True">
    <Menu DockPanel.Dock="Top">
        <MenuItem Header="_File">
            <MenuItem Header="_New"/>
        </MenuItem>
    </Menu>
    <Grid>
        <igDock:XamDockManager x:Name="dockManager" Theme="Aero">
            <igDock:DocumentContentHost>
                <igDock:SplitPane>
                    <igDock:TabGroupPane>
                        <igDock:ContentPane Header="Header 1">
                            <TextBox Text="Some Text"/>
                        </igDock:ContentPane>
                        <igDock:ContentPane Header="Header 2">
                            <TextBox Text="Some Other Text"/>
                        </igDock:ContentPane>
                    </igDock:TabGroupPane>
                </igDock:SplitPane>
            </igDock:DocumentContentHost>
        </igDock:XamDockManager>
    </Grid>
</DockPanel>

Answer 1

The visual studio team has some good information on lessons they learned when making VS in WPF. One of the issues they ran into was related to Focus management. As a result, WPF 4 has some new features to help out.

Here’s the info on the issue that sounds like your situation:

http://blogs.msdn.com/b/visualstudio/archive/2010/03/09/wpf-in-visual-studio-2010-part-3-focus-and-activation.aspx

Their discussion of the new “HwndSource.DefaultAcquireHwndFocusInMenuMode” property sounds very similar to what you’re running into.

EDIT

After further investigation, it looks like Visual Studio might be hooking the windows message loop and returning specific values to make the floating windows work.

I’m not a win32 programmer, but it seems that when a user clicks a menu in an inactive window, windows sends the WM_MOUSEACTIVATE message to it before processing the mouse down event. This lets the main window determine whether it should be activated.

In my unmodified WPF test app, the inactive window returns MA_ACTIVATE. However, VS returns MA_NOACTIVATE. The docs indicate that this tells windows NOT to activate the main window prior to handling further input. I’m guessing that visual studio hooks the windows message loop and returns MA_NOACTIVATE when the user clicks on the menus / toolbars.

I was able to make this work in a simple, two window WPF app by adding this code to the top level window.

    protected override void OnSourceInitialized(EventArgs e)
    {
        base.OnSourceInitialized(e);

        var hook = new HwndSourceHook(this.FilterMessage);
        var source2 = HwndSource.FromVisual(this) as HwndSource;
        source2.AddHook(hook);
    }

    private IntPtr FilterMessage(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
    {
        const int WM_MOUSEACTIVATE = 0x0021;
        const int MA_NOACTIVATE = 3;

        switch (msg)
        {
            case WM_MOUSEACTIVATE:
                handled = true;
                return new IntPtr(MA_NOACTIVATE);
        }
        return IntPtr.Zero;
    }

In your case, you’d probably need to add more logic that would check what the user clicked on and decide based on that whether to intercept the message and return MA_NOACTIVATE.

EDIT 2

I’ve attached a sample WPF application that shows how to do this with a simple WPF application. This should work pretty much the same with floating windows from a docking toolkit, but I haven’t tested that specific scenario.

The sample is available at: http://blog.alner.net/downloads/floatingWindowTest.zip

The sample has code comments to explain how it works. To see it in action, run the sample, click the “open another window” button. This should put focus in the textbox of the new window. Now, click the edit menu of the main window and use the commands like “select all”. These should operate on the other window without bringing the “main window” to the foreground.

You can also click on the “exit” menu item to see that it can still route commands to the main window if needed.

Key Points (Activation / Focus):

1. Use the HwndSource.DefaultAcquireHwndFocusInMenuMode to get the menus to work stop grabbing focus.
2. Hook the message loop and return “MA_NOACTIVATE” when the user clicks the menu.
3. Add an event handler to the menu’s PreviewGotKeyboardFocus and set e.Handled to true so that the menu wont’ attempt to grab focus.

Key Points (Commands):

1. Hook the main window’s “CommandManager.PreviewCanExecute” and “CommandManager.PreviewExecuted” events.
2. In these events, detect whether the app has an “other window” that’s supposed to be the target of events.
3. Manually invoke the original command against the “other window”.

Hope it works for you. If not, let me know.