Collapsing nodes

I love the diagramming controls.  They meet all of my client's requirements, except possible one.  Is it possible to wrap nodes into hierarchical groupings that can be independantly collapsed (like this)? 

I would also love to see formal support for child flows.  I've read that some people have managed to do it, so I'll be looking into that, but formal example code would be helpful.

Hello

We do not currently support node grouping, but it may be possible to achieve this by creating a custom diagram node that represents a group. Diagram nodes have a Parent property which returns null by default. You can create custom nodes that override the Parent property so that you can set it. This will allow you to build up the hierarchecal structure. In the setter of this Parent property, you can attach an event handler to the BoundsChanged event of the parent to provide logic such as if the parent moves, the children can move too, and if a group is collapsed, the children can be made invisible. This Parent property would need to be overriden on all types of nodes (group nodes and child nodes). The difficult thing will be how to route the connections when a group is collapsed.

I can take a more in-depth look at this on Friday to create a sample or/and include grouping support in the foundation if possible. Or let me know if you plan to implement this yourself. Also, I'm not sure what you mean by 'child flows' so an example would be appreciated. Good to hear the diagramming controls are working well for you.

Regards
 - Jason

Hello

Just letting you know I've been working on a sample to demonstrate how you could achieve hierarchecal node grouping. I have attached an image displaying what I've created so far. I'm still working on the expand/collapse feature and will get back to you with more details tomorrow.

 - Jason

Wow.  That looks very promising!!  I'm looking forward to seeing the example code.

I'm looking to use the diagramming controls to model execution process across many servers.  There is a single control server with workflow nodes mapped to commands to execute, and at various stages in that workflow it delegates to groups of target servers (of different classes, each executing the same "child" workflow).  I was imagining one custom node with custom data that listed the set of servers to execute on and the diagram of workflow activity to execute on each target server.  I think I'll be able to write this, have the UI bind the sub-diagram to a control when the node in the control diagram is selected.  I haven't woked out the serialization as of yet, though.

I have a separate need for grouping, like what you're working on.  The control workflow is very complex and having the option to collapse areas not being worked on will be a huge usability feature. 

Hello

I have attached the sample that demonstrates how to implement node grouping, including collapsability. It worked out really well with just a couple of edge cases which I'll work on next week. To run the sample, make sure to include a reference to your WpfDiagramming.Foundation.dll. I needed to make a few changes to the core in order to fix some graphical bugs, so you should download the latest nightly build to resolve most of these. (A few more fixes will be comming early next week).

I wasn't sure if you are just planning to build up the hierarchecal structure in code, or if your application will allow users to build the heirarchecal diagram using the UI. For the purposes of the NodeGrouping sample, I have included a way to group nodes together by dragging and dropping nodes onto a group. (This can be done either by dragging from the diagram toolbox, or dragging nodes that are already on the DiagramSurface). At the moment, once a node has been added to a group, it can not be removed from the group using the UI. Let me know if you will need help with implementing this if you need it.

Have a play around with the sample to see if it's what you were expecting, and look through the code to see how I implemented the various parts. Let me know if you have any questions about any of the code, or any other details your looking for in the grouping feature.

 - Jason

Hello

The latest version of the node grouping sample is now available through the current nightly builds: http://assets.mindscape.co.nz/Trial/Nightlies/20110711/WpfDiagramsTrial-20110711.msi

The NodeGrouping sample has been included in the samples solution and the Sample Explorer application. Here is a blog post about it containing an outline of how it was implemented and a video demonstrating how to use the sample: http://www.mindscapehq.com/blog/index.php/2011/07/11/mindscape-wpf-diagrams-node-grouping/

Let me know if you have any questions about implementing it in your application, or if you need help with adding additional functionality to the grouping feature.

 - Jason

Hello! Unfortunately, link to MSI file doesn't work. Could you please provide another one to such sample. I downloaded zip with the sample from your previous post, but seems it works incorrectly with the last version of DLLs. Please see attached file for explanation.

Hello

Sorry for the broken link. You can download the latest nightly builds from this page here: http://www.mindscapehq.com/products/wpfdiagrams/nightly-builds

You'll want to ditch the prototype sample from the previous post as this is where the issues are coming from. The grouping sample is available within the WPF Diagrams install itself. Open the windows start menu and go to Mindscape -> WPF Diagrams -> Sample Explorer. When the Sample Explorer is running, you'll see a list of samples down the left side. Click on "Node Grouping" then click the "Launch Sample" button that appears to the right. You can also click "Open Sample in Visual Studio" to see the code.

Alternatively you can go to the directory where you installed WPF Diagrams and go to the Mindscape/WPF Diagrams/Samples folder. Here you can find all the samples we provide. You can go to the NodeGrouping folder and open up the sample in visual studio.

Let me know if you have any questions.

Jason Fauchelle

Hello!

Thank you, that works fine. But I have one more question that doesn't concern to grouping directly. When I connect one link to another, I need to add an additional node instead of connection point to make this connection point playing as a node. Please see the attached pictures. Assume I have configuration as showed on pic1. If I collapse the group node, I will see the situation as showed on pic2 - outgoing link from the group node is not hided. But I want it should be like on pic3. I think it can be solved by adding additional node that will be included in the group and then hided when group is collapsed. But I don't know what event should I catch exactly. I mean event occured when I connect something with a link. Could you please help me with this?

Hello

One way to handle this situation would be to include some additional logic in the GroupableNode implementation to support hiding connection-mounted-connections. In the GroupableNode class in the sample, you could add some methods that recursively follow connections to find the destination node. a simple implementation of such methods would look like this:

private GroupableNode GetToNode(CollapsableConnection connection)
{
  GroupableNode node = connection.ToConnectionPoint.Connectable as GroupableNode;
  if (node == null)
  {
    CollapsableConnection toConnection = connection.ToConnectionPoint.Connectable as CollapsableConnection;
    if (toConnection != null)
    {
      node = GetToNode(toConnection);
    }
  }
  return node;
}

private GroupableNode GetFromNode(CollapsableConnection connection)
{
  GroupableNode node = connection.FromConnectionPoint.Connectable as GroupableNode;
  if (node == null)
  {
    CollapsableConnection fromConnection = connection.FromConnectionPoint.Connectable as CollapsableConnection;
    if (fromConnection != null)
    {
      node = GetFromNode(fromConnection);
    }
  }
  return node;
}

Then in the IsVisible property setter, you would replace the core logic with the following code that uses the 2 recursive methods:

GroupableNode fromNode = GetFromNode(collapsable);
GroupableNode toNode = GetToNode(collapsable);
if (fromNode != null && toNode != null)
{
  // if both ends of the connection have a common collapsed group node ancestor, then hide the connection, otherwise let it be visible.
  GroupNode fromCollapsedParent = fromNode.GetCollapsedParent();
  GroupNode toCollapsedParent = toNode.GetCollapsedParent();
   collapsable.IsVisible = fromCollapsedParent == null || fromCollapsedParent != toCollapsedParent;
}

If this solution is not going to work for you, you can go with you're additional node idea. There are 2 different ways to listen to when a connection has been created:

1) One way is to get the diagram model and cast the Connections property into an INotifyCollectionChanged. from this you can listen to when connections have been added. In the NodeGrouping sample for example, you can get an IDiagramModel from the Diagram property of the DiagramSurface. When you have the IDiagramModel, cast its Connections property to an INotifyCollectionChanged. When you have this, attach to its CollectionChanged event. Then in the event handler you will be able to know when connections have been added.

2) The other way is to build a custom connection builder. The NodeGrouping sample includes a custom connection builder since it has its own custom connection implementation. This can be found in the ConnectionBuilder class in the sample. The CreateConnection method is called whenever a connection needs to be created. Here you can see this method is actually creating the connection and adding it to the diagram model. You may find this is a good place to include the additional logic for adding your additional node. By looking at the fromConnectionPoint and toConnectionPoint parameters, you'll be able to see if the new connection is going to connect to another connection or a node.

I hope these suggestions point you in the right direction for implementing this functionality. Let me know if you have any questions.

Jason Fauchelle

Hello Jason!

Thank you for the answer. Seems I resolved this problem.

But I faced with another strange behaviour:

I made nodes rotatable (ds.CanRotateNodes = true), then put some nodes on the surface, rotated them and then dragged some rotated nodes to a group node. And I saw it was ugly. Please take a look at the attached picture. Could you fix it?

And one problem else. If I drag a node out of a group node, I assume it should be excluded from the group, but actually it is not so.

And the last. In some cases I see that links connected to a group node can overlap after group was collapsed. Please see attached files (beforeCollapsing.jpg and afterCollapsing.jpg). I hope they can explain the issue. I want to keep the order for the links after collapsing. Could you please give me an advice how to fix it?

Hello

Good to hear you got the additional node working. From the images you sent, the application you are working on looks very interesting!

The ability to group nodes together is not a built in feature, this is why some of these things don't work in the sample. The Node Grouping sample simply shows how it is possible to implement grouping yourself. Some things like removing nodes from a group have not been implemented in the sample.

We'll look into these things and get back to you with the solutions soon.

Jason Fauchelle

Hello Jason!

I solved the problem with links overlapping.

But the problems with rotated nodes and excluding nodes from the groups still exist.

Dmitry

Hello Dmitry

In the next nightly build these issues will be solved. For the rotating nodes issue, I updated something in the foundation dll which will solve this for you.

For excluding nodes from a group, I have extended the functionality of the NodeGrouping sample. When you get the next nightly build, run the NodeGrouping sample that comes with WPF Diagrams. You will see that dragging a node away from its GroupNode parent will cause the GroupNode to have a red border around it. This indicates that the node can be removed. By letting go of the mouse, the node is removed from its parent. You can confirm this by dragging the GroupNode and see that the node you removed no longer moves with the parent. I have also allowed users to drag a node out of its current GroupNode and drop it into another GroupNode in a single drag operation.

I'm guessing that you've taken code from the NodeGrouping sample and used it to implement grouping in your own application. So when you get the next nightly build, you'll need to go through the new NodeGrouping sample and copy over the changes I made.

The GroupNode class now has an IsChildLeaving property. This is set to true when the user is dragging a GroupableNode away from its GroupNode.

The DiagramStyles.xaml file includes a new DataTrigger at line 81-84 that listens to the IsChildLeaving property to make the border red when necessary.

In MainWindow.xaml.cs I made changes to the DiagramSurfaceNodeDragCompleted, SetParent and DiagramSurfaceQueryDropPositionEvent methods.

All these changes will be in the next nightly build available from around 1200 GMT (about 12 hours from now). Nightly builds can be downloaded from the downloads page: http://www.mindscapehq.com/products/wpfdiagrams/nightly-builds

Let me know if you have any questions about this.

Jason Fauchelle

Hello Jason!

Thank you very much for help.

Rotation works well. But I have found one strange issue with nodes grouping. The sequence was the following:

1. Add a group on a surface (see pic1.jpg)
2. Add a node on a group and select the added node (pic2.jpg)
3. Add another node on a group and select it (pic3)
4. Try to collapse the group (pic4).

And I see that the nodes don't belong to the group (or sometime it may be one of the nodes, not all).

Could you please help me to fix this issue?

Dmitry

Hello Dmitry

Thanks for pointing this out. I had come across this kind of bug and thought I'd fully resolved it. To fix this situation, I updated the first condition in the DiagramSurface_NodeDragCompleted method:

if (thumb != null && (e.HorizontalChange != 0 || e.VerticalChange != 0))

So now the re-parenting logic will not be used at all if the node did not move - for example if the node was simply selected. This update will be available in the next nightly build.

Jason Fauchelle