Hi, I'm trying to hide docking indicators when it is not possible to dock on a certain side. I started by copying the docking indicators as illustrated in the example "Customizing the DockIndicators" in the feature browser, so the code below closely resembles that. I already partly succeeded, but the center docking indicator is behaving strangely however. It is still showing the docking indicator untill at the moment the mouse enters the symbol, then it disappears. The following piece of code is not working as expected (I left out unimportant pieces):
<!-- Left Indicator --><igWindows:CardPanel x:Name="PART_DockLeft" ...> <Grid x:Name="leftIndicatorIcon" IsEnabled="{TemplateBinding CanDockLeft}" ...> <Ellipse x:Name="leftIndicatorBorder" ... /> <Viewbox ...> <Path x:Name="glyphLeft" ... /> </Viewbox> <Grid.Style> <Style TargetType="Grid"> <Style.Triggers> <DataTrigger Binding="{Binding Path=CanDockLeft, RelativeSource={RelativeSource Mode=TemplatedParent}}" Value="False"> <Setter Property="Visibility" Value="Collapsed"/> </DataTrigger> </Style.Triggers> </Style> </Grid.Style> </Grid></igWindows:CardPanel>
So basically I only added the style trigger. I also tried setting the Visibility property directly using a binding and a value converter, but that resulted in the same effect.
Hi,
I'm not able to see any impact on the any of the docking indicator from the code snippet you provided.
Could you please provide an image of what you are seeing? It would also be helpful if you could explain when “it is not possible to dock on a certain side”.
I’m attaching my sample where I have two forms, one is directly taken from the feature browser, the other has docking indicators that are a little less elaborate compared to the feature browser sample and I’ve added color to each indicator so that they are more visible. I did incorporate the same DockingIndicator style into my sample form so we can work with either that seems most helpful.
As I understand what you provided, it looks like you applied the style trigger directly on the PART_DockLeft, which is an element of the centerIndicator controlTemplate. I believe what you will need to do is add style triggers to the DockingIndicator style.
It may be most helpful if you could modify my sample to illustrate what you have done.
Hey Marianne,
With "it is not possible to dock on a certain side" I mean that panes can either be docked left or right. It depends on a system setting which can be changed. I altered the code you provided so you can see what I mean.
Problem #1:When you start the sample application, you'll see the 3 panes floating. When you want to dock them and start dragging them when you'll notice both the left and right docking indicators are visible. If you drag the pane over the left indicator it will disappear. Is it possible to just hide it when you start dragging?
Problem #2:The 2nd problem occurs when all 3 panes are docked to the right side and you want to rearrange them. When you start dragging one of the panes and drag it over another, you'll notice the center icon is present. When you enter that area, you'll see that the icon disappears. Same question here!
If it is still not clear what I mean, you can take a look at the code that I added. It is based on the previous samples. I added a viewModel on which the system property is defined. This property is not yet being used however, because I'm not sure how to do it. It does illustrate what my intention is though.
By following these steps I hope that my intentions are more clear:
Hi
I’ve added some view models and converters to your sample.
First I added a view model for the AllowDocking right and left that is bound to a resource that can be used by all of the panes to indicate to which side they should be able to dock. That resource value is reversed when you click on the button.
And the AllowDocking right and left are also passed a value converter to compare the parameter to current docking side value and return true or false.
In the style, the Center Indicator’s visibility is bound to an additional property in the DockInds, instead of using your multiValueConverter TestConverter, I’m using a Boolean, CanDockInTabGroup, to control whether the Center Indicator is collapsed. This is similar conceptually to what we did for the right and left indicators.
You’ll notice that when you drag the orange colored form you see the Center Indicator and you can docked in a tab group but only on the content host. The other content panes can not be docked in a tab group and you do not see the center indicator.
Initially you only see the right indicator. If you click on the Change Docking Side button, you will update the resource and see the left indicator.
Please let me know if you have further questions.
Sorry, it's still not working as it's supposed to... Although it is getting closer!
All panes should be able to be tabbed in the blue window, so I set AllowDockingInTabGroup to True for the 3 panes. This has the side effect that panes can now also be tabbed within the panes themselves, meaning you can also tab red with green inside a dockable floating pane. This should not be possible, there should be only one tabbing area on the entire form (the blue area).
Is it perhaps possible to react to the dragging events? There has to be some kind of event, the same one that moves the docking indicators when entering another area. If I could react to that event and set the AllowXXX properties at that moment, I believe this problem could be solved.
I've been working thru a possible solution but I wanted to contact development concerning your questions. I'll update you shortly.
I submitted my sample to development and asked their assistance as to the best way to approach your request. I had the intention of creating another resource, similar to our CanDocInds, that would contain a boolean to which we could bind the AllowDockingInTabGroup of all of the ContentPanes. Then I added a PaneDragOver event for the DockManager. I was working on the idea that we could identify the FloatPaneAction in the PageDragOver event and perhaps identify the pane that is being dragged over before the dockingIndicators were created.
private void myDM_PaneDragOver(object sender, Infragistics.Windows.DockManager.Events.PaneDragOverEventArgs e)
{
if (e.DragAction is Infragistics.Windows.DockManager.Dragging.MoveWindowAction)
Infragistics.Windows.DockManager.Dragging.MoveWindowAction mwa = e.DragAction as Infragistics.Windows.DockManager.Dragging.MoveWindowAction;
//HitTestResult result = VisualTreeHelper.HitTest(DCH, mwa.NewLocation);
}
Our development staff provided the following information.
The PaneDragOver event is raised as the mouse is moved but after we have established the drop point which involves checking which element we are over and hit testing the docking indicators. It sounds like you want something that is raised before the docking indicators are shown and we hit test against them. I could be mistaken but the only way that would happen is if we add something – whether that is an event to determine the docking indicator states before we show the indicator or something else.
As a result of this comment I have submitted a feature request for you directly to our Product Management team concerning the ability to know when the dockingIndicators are about to be shown. Our product team chooses new feature requests for development based on popular feedback from our customer base. Infragistics continues to monitor application development for all of our products so as trends appear in requested features, we can plan accordingly.
Our philosophy is to enhance our toolset based on customer feedback. If your features are chosen for development you will be notified at that time. Your reference number is FR14112.
Development continues with these suggestions:
It may be possible for you to do something hackish like define an attached property that binds to the ToolWindow’s Owner property and then write some logic to initialize the CanDockInTabGroup of the panes being dragged. However there are potential issues – the drag may be cancelled and so you may not get the dragended and therefore may not be able to revert the CanDockInTabGroup back to the original/desired state, you would need to interpret what will happen based on the owner, etc.
If you want to try going down this road you would define an attached property like the following:
public static class DockingIndicatorTargetHelper
#region DockingIndicatorTarget
/// <summary>
/// Identifies the DockingIndicatorTarget attached dependency property
/// </summary>
/// <seealso cref="GetDockingIndicatorTarget"/>
/// <seealso cref="SetDockingIndicatorTarget"/>
public static readonly DependencyProperty DockingIndicatorTargetProperty = DependencyProperty.RegisterAttached("DockingIndicatorTarget",
typeof(object), typeof(DockingIndicatorTargetHelper),
new PropertyMetadata(null, new PropertyChangedCallback(OnDockingIndicatorTargetChanged))
);
private static void OnDockingIndicatorTargetChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
/// Gets the value of the attached DockingIndicatorTarget DependencyProperty.
/// <param name="d">The object whose value is to be returned</param>
/// <seealso cref="DockingIndicatorTargetProperty"/>
public static object GetDockingIndicatorTarget(DependencyObject d)
return (object)d.GetValue(DockingIndicatorTargetHelper.DockingIndicatorTargetProperty);
/// Sets the value of the attached DockingIndicatorTarget DependencyProperty.
/// <param name="d">The object whose value is to be modified</param>
/// <param name="value">The new value</param>
public static void SetDockingIndicatorTarget(DependencyObject d, object value)
d.SetValue(DockingIndicatorTargetHelper.DockingIndicatorTargetProperty, value);
#endregion //DockingIndicatorTarget
Then add a Setter to the DockingIndicator style:
<Style TargetType="{x:Type igDock:DockingIndicator}">
<Setter Property="local:DockingIndicatorTargetHelper.DockingIndicatorTarget" Value="{Binding Path=(igWindows:ToolWindow.ToolWindow).Owner, RelativeSource={RelativeSource Self}}" />
Since you are using a custom DockingIndicator we are simply using hittesting against the element to determine which indicator the mouse is over, if you hid or otherwise rendered particular indicators as not hittestable then we wouldn’t try to use that as a drop point.
So if you just want to know if the docking indicator is being shown for the DocumentContentHost then maybe you can do something like the following:
SetTargetIsDocumentHost(d, e.NewValue != null && XamDockManager.GetPaneLocation(e.NewValue as DependencyObject) == PaneLocation.Document);
#region TargetIsDocumentHost
/// Identifies the TargetIsDocumentHost attached dependency property
/// <seealso cref="GetTargetIsDocumentHost"/>
/// <seealso cref="SetTargetIsDocumentHost"/>
public static readonly DependencyProperty TargetIsDocumentHostProperty = DependencyProperty.RegisterAttached("TargetIsDocumentHost",
typeof(bool), typeof(DockingIndicatorTargetHelper),
new PropertyMetadata(false)
/// Gets the value of the attached TargetIsDocumentHost DependencyProperty.
/// <seealso cref="TargetIsDocumentHostProperty"/>
public static bool GetTargetIsDocumentHost(DependencyObject d)
return (bool)d.GetValue(DockingIndicatorTargetHelper.TargetIsDocumentHostProperty);
/// Sets the value of the attached TargetIsDocumentHost DependencyProperty.
public static void SetTargetIsDocumentHost(DependencyObject d, bool value)
d.SetValue(DockingIndicatorTargetHelper.TargetIsDocumentHostProperty, value);
#endregion //TargetIsDocumentHost
Where the attached TargetIsDocumentHost would be true/false on the DockingIndicator based on the Owner that the indicator is associated with.
Please let me know if you have questions.
HI,
You are very welcome. I’m sure that I have given you the best advice that I can. Andrew is the developer who responded to my question. You may have seen many of his other posts.
Please let me know if you have further questions on this topic.
Hi Marianne,
I will certainly try this approach and investigate it further, but knowing that it is a "hack" approach with possible unwanted behavior it is probably not going to be implemented in the final solution. The program is intended for our customers after all so it should work without any problems, if it were for internal staff it wouldn't matter that much.
In any case, thanks for helping me out here. I also appreciate that you posted a feature request and I hope that it will be implemented so that I can come up with a clean approach to this problem.
Kind regards,
Stefan