walter, I found that in the new beta 2.5 GoDiagram EndSegmentLength is actually used to seperate overlapped links (the same idea on my previous post ). But I don’t know why there are some limitations for this to work, which is written in the document.
By the way, by increasing/decreasing EndSegmentLength along one side of a node, a new problem will come out, which is how to minimize the number of crosses between links.
For example, if EndSegmentLength increasing along one side of a node and all the links (Orthogonal) from/to these ports go down, there will be a lot of crosses. In this situation, EndSegmentLength should be set in reverse order.
I come up with a solution(not very efficient) for both of these problems.
Basically, whenever the number of ports changes or the node position changes, I recalculate the ports’ EngSegmentLength based on:
- Their position
- The first turn direction of the links (I’m using Orthogonal links only)
I defined two arrays, one for ports with going down link(array one), another one for ports with going up link (array two).
And then I set EndSegmentLength of ports in array one decreasingly (or increasingly in reverse order) and I set those in array two increasingly. Every port has different EndSegmentLength.
This solution works great for my development except an amount of penalty of speed loss. It’s obvious in my work because in some nodes, there are about 20 links, and when node is moved, I need to recalculate the paths of the links.