Dear Infragisitics Team,
I have a problem dealing with the docking behavior of DockManager.ContentPanes in WPF.
Background:
(Using MVVM in C#) I have a main window (WPF) that contains a ribbon and various content panes.
(That ribbon is subdivided into ribbon groups providing several actions.)
Description:
Depending on which content pane is selected the ribbon activates associated groups with a set of actions.
As long as the content panes are docked to the main window all works well, according to the expectations. (I am able to change the panes and I’ll get the actions selected in the ribbon.)
When some panes are undocked, I am only allowed to change between these undocked panes to get the expected behavior after selecting an action in the ribbon (of the main window).
But problems (with the undocked panes) occur after clicking onto a pane that is docked to the main window.
Thereafter the undocked panes seem not to work any longer.
I am able to click on the ribbon groups associated with these undocked panes. Although it seems as if I could select an action within such a ribbon group nothing happens any more.
More details:
It seems to matter whether the ribbon groups are assigned to "XamRibbon.Tabs" or to "XamRibbon.ContextualTabGroups".
All is fine with the "XamRibbon.Tabs”.
But the problem described above only occurs as long as the ribbon groups are assigned to "XamRibbon.ContextualTabGroups”.
I tried to figure it out myself by registering a specified action in such a ribbon group to a "PreviewMouseLeftButtonDown" event and a “Click” event.
Inside of the corresponding event handlers I checked the data context.
As long as the error does not occur both event handlers are called. Then the (view model of the control defining the) selected ribbon group is the data context.
When the error occurs (according to the description above) only the PreviewMouseButton event is executed. Then the (view model of the) main window is the data context.
It seems as if I lose the focus on the correct ribbon group.
Shouldn’t the "ContextualTabGroups" behave the same in this context as it is expected by the "XamRibbbon.Tabs"?
Best,
Stephan.
Hi Stephan,
How are you switching the RibbonGroups activated exactly? Are you just binding their Visibility to some view model property? If so, how do you control that visibility property when you select a ContentPane? Theoretically the RibbonTabs and Groups located in the ContextualTabGroup or XamRibbon.Tabs should work the same way but something to note is that undocked ContentPanes (floating panes) are actually rendered in a different window. They are no longer contained inside the MainWindow so it's possible that is interfering with something.
Let me know exactly how you are activating the RibbonGroup so I can build a sample that does this and try to reproduce this. Unless you already have a sample you can send me. ;)
Hi Rob,
First I thank you for your quick answer.
As you proposed I add a sample to this email.
To answer your question, the ribbon groups are switched in code behind in order to activate the selected one.
Sample code:
The sample is a simplified stripped-down piece of code that only reflects the part that is related to our problem. I chose a simple form of communication, triggered by actions, selected from a ribbon group. These actions result in an update of an associated content pane.
One case demonstrates a simple notification. The second one is an example of switching colors. These examples are designed only to get an idea how the communication between the components work.
Description of the UI:
The main window of the UI contains a ribbon.
As described in the last email the problem occurs with ribbon groups that are part of a ContextualTabGroup.
Also the XamRibbon.Tabs show the same behavior. (Recent tests have proven me wrong. So this is a correction to my assertion in the last email.)
I chose three content panes that are associated with ribbon groups.
By clicking onto a pane its related ribbon group is set to be visible. (Except for the first pane the associated ribbon group (that is part of a contextual ribbon group) of the selected pane is set to the front.)
ContextualRibbonTabs:
Please refer to the "Notification" example demonstrated by the third pane. It has a text box on the left side in which you can type a message to be sent. On the right side is a label that is meant to receive this message.
In order to notify the label to the right you will need to click onto a button in the corresponding ribbon group. In this sample the text box (the sender) and the label (the receiver) communicate via the view model of the 3rd content pane.
As long as the 3rd pane is docked to the main window all is fine.
Also when all panes are floating the communication between these controls works well. In this case you might activate pane 1 or 2 in the meantime without causing any interferences to the communication of the 3rd one.
But when you set the 3rd pane to be floating while there is one pane docked to the main window the communication is broken. (Functionality can be restored only by setting all panes to be floating again.)
XamRibbon.Tabs:
Please refer to the 1st pane and the main ribbon group for the example with "Switching Colors". As mentioned above it shows the same strange behavior.
Summary:
In both cases, the status of the UI, presented to the user, is different to its actual usability.
The ribbon group, connected to the corresponding content pane, appears to be usable. But after clicking on the button (in the ribbon group) its click event is not executed.
This is due to the lost visibility of this ribbon group preceding the handling of the event. Instead the ribbon group of the topmost pane in the main window is activated.
From the viewpoint of the user, this seems to be a malfunction, for the requested action (intended by the user) fails to be performed.
Do you have any idea how to get the click events to be executed?
Sincerely,
I think I see what issue you are referring to. If I drag Pane 3 out so that it is undocked and try to click on the Notify button in Tab 3 the button is disappearing and I can see that the tab changed to Tab 2. This changing to Tab 2 is why the button disappears.
Now unfortunately I think this is expected behavior because the XamDockManager's active pane is largely determined by which pane has keyboard focus. When you drag out Pane 3 it gets placed into it's own window and given keyboard focus. After you click back on the main window to select the Notify button this is placing focus back in the main window which then changes keyboard focus to a different pane in the XamDockManager (since Pane 3 is currently inside another window). Since the keyboard focus changes it triggers your code that then changes the visible tab.
I think you are going to need to track which pane is active a different way that doesn't 100% rely on keyboard focus. For example, if keyboard focus changes you could see if the previous focused pane was floating (undocked) and if so, check somehow if keyboard focus changes as a result of the user clicking on a different pane or because they just refocused the main window and did not click on the dockmanager. This would probably be tricky though.