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.
