Reading link points

Is there any way we can read the link segment, start and end points in document coordinates? The link.points are not predictable they would give the exact point where segment bend starts or end.

Between transactions the value of Link.points is the route of the link, in document coordinates.

If you look at the route during changes to the diagram, such as when a node has changed position or size, the route might be invalid, holding old information until the route can be recomputed.

I wanted to read the points on link, where bends start or end, for orthogonal links, which is not possible using link.points. May I know, if this is possible.

I don’t understand what your question really is. If I look at the value of Link.points of a Link in a running diagram in the console window, I get:

>> myDiagram.selection.first().points.each(p => console.log(p.toString()))

So you can easily see where the “bends” are by looking at whether adjacent points have the same or different values for x and y.

there is a lot of iteration needed within points logically to get the exact locations, Is there any other parameter that would directly give this information?
Basically, I am trying to make the orthogonal link straight, without segments, if user has drawn a link with segments, having segment length less than a reference length. This is straightforward when there are no toEndSegmentLength or fromEndSegmentLength.
When there are toEndSegmentLength or fromEndSegmentLength for the node, I have to check for bends, after the endSegmentLengths.
Do you think is there a better way to remove the segments to make the link straight?

If I understand you correctly, when the total distance is less than some number, you want to change the route to just have two points so that it’s just a straight line running from the start point link.points.getPoint(0) to the end point link.points.getPoint(link.pointsCount-1).

The best way to do that is to define a custom Link class and override Link.computePoints to call the super method, if successful look at the results for the criteria you care about, and if you want to, call Link.removePoint on all of the intermediate points you don’t want to keep in the route.

Its not “when the total distance is less than some number”. its when the link has shape as in picture, straighten them.

The circled distance when below some number, the link has to straighten. The node might have endSegmentLengths, which makes it tedious to not consider just link.points.getPoint(0) to the end point link.points.getPoint(link.pointsCount-1) . [Eg: 2nd diagram]. The link should starighten, without removing the end segments as below:

In the first case, are you saying that you would want one of the link connection points to no longer be at the middle of the bottom or the middle of the top of a node? Otherwise it isn’t clear to me what you want.

This doesn’t handle the second case in your upper screenshot, but a number of samples implement a custom Link class, typically called BarLink, that has the route always be straight to a “Bar” Node if the route can be straight without dangling mid-air. Look at:
Network Configuration
Grafcet Diagrams

In the first case the encircled part should be removed, and the whole link should be straight, between the 2 blocks, without moving the start and end points, since the connections happen between ports.

OK, so the route would no longer be orthogonal.

Yes, you do need to respect end segments. It’s not hard – if there are 4 or more points you can look at getPoint(1) and getPoint(pointsCount-2) instead. This assumes that you don’t have any cases where the fromSpot or the toSpot is None.

Yes you got it right. But, The nodes may or may not have segments, like in the first picture, there are no end segments.
But when I examine the getPoint(1) and getPoint(pointsCount-2), they are not always the point which we thought we would get, just now.

Did you have an example you could share along with a question to ask? Or have you figured it out already?

Ok I shall find out an example to post here soon.