As I recall (but cannot find in the change log), you improved routing of links between a group and its members to be “internal” without going outside of this group. I see this working if a group has just one member, but starting with a second member routing goes outside the group.
I just tried this, and although the routing is not always optimal, the routing is always “correct” in terms of what objects appear to be connected.
Could you show us a minimal example demonstrating the problem that you are seeing. You might want to simplify as much as you can and discuss the relationships of the objects.
I am working on an example and will be done tomorrow. While doing so, using large arrowheads I found that even with one member it does not work correctly. Here is a screenshot.
What are the Diagram.layout and Group.layout?
What are the fromSpot and toSpot on the Link template (if specified) and on the Node’s ports and on the Group’s ports?
Thank you Walter,it was it: missing toSpot & fromSpot setting for group ports.
After changes in group port templates as following I got it working as expected!.
Layouts are default, but the same was happening if I had different ones for groups
$go(go.Shape, "Circle",
{
desiredSize: new go.Size(4, 4),
alignment: go.Spot.LeftCenter,
fromLinkable: true,
toLinkable: true,
toSpot: go.Spot.Left,
fromSpot: go.Spot.Right,
strokeWidth: 2,
stroke: "black",
portId: "IN"
}
),
$go(go.Shape, "Circle",
{
desiredSize: new go.Size(4, 4),
alignment: go.Spot.RightCenter,
fromLinkable: true,
toLinkable: true,
toSpot: go.Spot.Left,
fromSpot: go.Spot.Right,
strokeWidth: 2,
stroke: "black",
portId: "OUT"
}
),...
You might be interested in this sample: Basic GoJS Sample
Although it is oriented vertically instead of horizontally, I think it exhibits the same kinds of features you seem to be interested in.
Oh, here’s the same sample but where the links have two “Standard” arrowheads:
I think the arrowheads are superfluous and distracting.
Thanks.
I am working on a custom link implementation which will “tunnel” individual links between nodes - members of groups - into their group single IN - single OUT ports without splitting into multiple links - in which case it can be similar to your example.
The reason to do so is to maintain true business relations between nodes in the model and simplify operations on them. This is how it looks (after I fixed my port templates :-) ):
What you see is my first cut of it. I define hierarchy of groups between fromNode and toNode, within computePoints() use a temporary link and, recursively setting intermediate to and from points and ports, execute temp link computePoints() and then adding temp link points to the list of resulting points. It already works, but so far fails to properly adjust on objects move and group collapse, which I will try to fix via event handling.
If you have something in mind what might help me in this effort - please let me know.
I guess I don’t understand why you do not want links going directly between N10 node 2 and N5 node 1. The merging that you are trying to do (if I understood you correctly) would confuse the relationships/dependencies when the subgroups are expanded.
A diagram I am working on has many nodes (a few hundreds) and multiple IN and OUT links (dozens) on each of them. In order to make such a diagram useful, business wants to de-clutter it by co-locating as many segments of links as possible.
Visibility of individual links can be achieved, for example, by highlighting them programmatically based on business attributes and/or hover over a node etc. In case of 2 groups, visually “single link” between them will actually represent overlapping subset of many links between member’ nodes (the same way as a “link” between collapsed group).
I guess this context explains what I am up to…
OK, that makes sense. If you have any particular questions, we’re here to try to answer them.
Alternative strategies could include de-emphasizing links, perhaps by decreasing their GraphObject.opacity, unless they should be “highlighted” programmatically and/or by hovering.