Floating and Routed Events

Docking/MDI for WPF Forum

Posted 9 years ago by Matthew Zanni
Version: 9.2.0513
Avatar
I'm writing a program that requires that a Click Event of a button in a Document Window reach the main application via a Routed Bubbling Event.

It works fine if the Document Window is Docked within a Container, but when I Float the Document Window the event no longer can reach the main application.

Is there something I can do to allow the connection, that allows RoutedEvents, between my Dockable Windows and the main application to remain connected when I float the windows?

Comments (3)

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

Assuming you are not using hosted windows (which are not real windows), you would probably need to add a class handler for RaftingWindow. There isn't a way to "forward" the events automatically, as WPF is handling all that. This article explains a bit about class handlers: http://msdn.microsoft.com/en-us/library/ms747183.aspx

[Modified at 05/06/2010 09:13 AM]


Actipro Software Support

Posted 8 years ago by Keith I
Avatar
I have the same problem but I think that the scope of it is more than just the handling of routed events.

I think that floated (undocked) windows don't correctly handle focus. They seem to no longer be children of the main window as far as focus is concerned.

You can see the problem in your Docking Features sample (/ProductSamples/DockingSamples/Demo/Features/) by doing the following:
- Select a word in WelcomeDocument.rtf
- Open the Edit menu and you will see the Copy menu item is available
- Float WelcomeDocument.rtf
- Select a word in WelcomeDocument.rtf
- Open the Edit menu and you will see the Copy menu item is unavailable.

It becomes worse if you are using your Ribbon control along with docking. In that case clicking on the ribbon will steal focus from a floating window and set it to the last activated docked window.

I wonder if this is the same as the issue detailed here: https://connect.microsoft.com/VisualStudio/feedback/details/495525/opening-activating-and-focusing-a-child-window-from-treeview-causes-focus-hittest-issues. As you can see from that link the described problem is apparently fixed in .NET 4.0.

I am using v10.2.0531, which I believe is using .NET 3.51. If this problem is fixed in .NET 4.0, then do you have a plan to release a version of ActiPro using .NET 4.0, or a plan to workaround the problem in some other way.

Without this being fixed I don't see that the ability to float documents is particularly useful, and I am going to have to switch that feature off in my application - even though it greatly improves my application.
Posted 8 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Keith,

There's nothing really special about the rafting (i.e. floated/undocked) windows. In fact you can reproduce the routing command issue using native WPF controls. Like:

1. Create new WPF application
2. Add a new secondary Window that contains a TextBox
<Window x:Class="WpfApplication1.Window1"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Window1" Height="300" Width="300">
    <Grid>
        <TextBox Text="Here" />
    </Grid>
</Window>
3. Add a Menu, TextBox, and Button to the main Window
<Window x:Class="WpfApplication1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <DockPanel>
        <Menu DockPanel.Dock="Top">
            <MenuItem Header="Edit">
                <MenuItem Header="Copy" Command="Copy" />
            </MenuItem>
        </Menu>
        <Button DockPanel.Dock="Bottom" Content="Open" Click="Button_Click" />
        <TextBox Text="Here also" />
    </DockPanel>
</Window>
4. Update the Button's Click handler to open the secondary window
private void Button_Click(object sender, RoutedEventArgs e) {
    Window1 w = new Window1();
    w.Show();
}
To reproduce the issue, you'd:

1. Open the secondary window
2. Select some text
3. Click the Edit menu item

You'll see that the focus is actually moved the main Window. If you select text from the TextBox in the main Window, the TextBox still looks "focused" (i.e. the text is selected). This is effectively what is happening with our Docking & MDI rafting windows.

This issue is known by Microsoft, and generally has to do with focus scopes and how the command routing works. Routed events can be "fixed" by adding class handlers as we mentioned before, but this doesn't help with routed commands.

There is a rather long discussion on the various issues this causes on MSDN, which may or may not help you out.


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.