still doest seem to fix the problem all the links are going to bottom of the next visible node instead of specified go.spot.left same goes for the fromspot
Are you using the override of findVisibleNode that was the primary reason for having a subclass of Node?
yes
“there is limit of 10 char on reply”
Odd. Well, let me wake up first…
1 Like
class MapperTreeNode extends go.Node {
constructor() {
super();
this.treeExpandedChanged = function (node) {
if (node.containingGroup !== null) {
node.containingGroup.findExternalLinksConnected().each(function (l) {
l.invalidateRoute();
});
}
};
}
// override which node the link appears to connect with, when the actual node is not isVisible()
findVisibleNode() {
// redirect links to lowest visible "ancestor" in the tree
var n = this;
while (n !== null && !n.isVisible()) {
n = n.findTreeParentNode();
}
if (n === null) {
// if whole tree is not visible, try the containing group(s)
n = this;
while (n !== null && !n.isVisible()) {
n = n.containingGroup;
}
}
return n;
}
}
OK, I think we have improved routing of links connecting with Nodes that are hidden (i.e. not isVisible()) because a tree parent Node is not Node.isTreeExpanded or a containing Group is not Group.isSubGraphExpanded and has fromSpot or toSpot that is a “…Side” Spot.
It will be a while before we can release 2.1.10 – we need to do some testing.
EDIT: I have put the library up at GoJS - Build Interactive Diagrams for the Web. You can see my simplification of your code at Minimal GoJS Sample. I think it looks pretty good now.
1 Like
We have released 2.1.10, so you can use GitHub, npm, NuGet, or our web site to get the latest version which, with the appropriate override of Node.findVisibleNode, should get you the results that you want.