Link appearing wrong when EndSegmentLengh is set

Good evening,

I am having problems conecting two nodes with a link. In the first picture below the right link from the blue node to the yellow node does not look well placed. I am trying to have the link go down exactly to the same height as the left link into the yellow node does.

I tried to set EndSegmentLength of the top node of the yellow node to zero. but then the arrowheads of the two links coming in this port vanished and the right link into the yellow node did not change at all. See pictures two.

My links are GoLabeldLinks.

What am I doing wrong?

EndSegmentLength sets the minimum size for the last segment. Arrows heads are drawn along that last segment. Setting it to zero isn’t giving the arrowhead anywhere to draw.

(assuming AvoidsNodes is off, which it appears to be in your case) An orthogonal link like the one from the false port is going to route half the distance to the destination, jog over, then down the rest of the distance. So that last vertical segment is really 2… the “end segment” logically coming up from the port and the “down segment” from the jog over down to the “end segment” point.

The routing algorithm for a particular link isn’t sensitive to how other links are being routed.

I can’t think of a simple way to get what you want.

You could… I hesitate to say this as I’ve never tried it… turn on AvoidsNodes on your links. Then change the logic of GoDocument.GetAvoidableRectangle(GoObject obj) so that the “Parameter Define” nodes actually return a width in part defined by the blue parent node. (in other words, a Parameter Define node on the true path would return a width of IFnode.Right - PDnode.Left.)

This would cause the false link to route around the artificially wide PD nodes. (You’d have to do this for any nodes on the false path to, but in the opposite direction.)

The type and number of nodes below either the “true” or “false” branch isn’t known untill the whole graph is layouted. But I didn’t know there was a method to return a avoidable rectangle… I will play around with it.

Once all layouting is done and I re-layout ONLY the one link from the “false” path to the yellow node I get following output. I have drawn a rectangle around each subtreee (and their coordinates) of the graph. Lets say the “true” branch returns a larger avoidable rectangle for each branch of the if-node, would the half of the width of the blue if-node be enough?

I hope you can still see the links actual path. The blue rectangles are the bounaries of the subtrees. Actually the boundary rectangle for the “then” branch is a bit smaller
in height as shown. I only added an offset for reading the coordinates
easier.

Is it possible to assign a certain position in the view to a
GoLabeldLink through which it must draw either vertically or
horizontally? Best case would be to assign its last curving position, in
my case it would be right above the yellow nodes’ top port.

Following your instructions I almost got my desired output. I have overriden GetAvoidableRectangle() to return a larger rectangle for certain nodes. However, if I use nested if-nodes the order of GoObjects to call the method is wrong in my situation. I need bottom up if-nodes evuation as the width and height of each branch depends on whole subgraph below.

Is there are way to control the order of GoObject.GetAvoidableRectangles() to be called?

If you wanted to re-route the false link… I’m assuming you can identify the two links coming into the Yellow node. (they would be the SourceLinks for the top port)

Both of those links should have 6 Points (simple orthogonal routing)

  1. from port
  2. end of initial segment (endsegmentlength)
  3. first point in horizontal segment
  4. next point.
  5. pt at end of endsegmentlength
  6. to port.

so… if you change the Y position of points 3 & 4 to be the same for the false link as the true link… you’re done. (you’d set the Y pos to match the other link)

if the line doesn’t have PointsCount = 6, it’s probably best not to touch it. (Turning on AvoidsNodes would invalidate this simple approach.)

----- now back to the avoidable rectangle approach

Lets say the “true” branch returns a larger avoidable rectangle for each branch of the if-node, would the half of the width of the blue if-node be enough?


no… for “true” branch nodes, you’d want the top,left and bottom of the bounds to stay the same and the right to be where you’ve drawn that blue line down from the right side of the If node.

I worked out both approaches.

For the re-routing I re-assigned point3 and point4 of orthogonal links AFTER all routing was done. I only needed to do this on links going into the yellow nodes. I had two mistakes. My 1st mistake was that I positioned nodes via Position() which implizit called GetMidOrthoPosition() which again returned wrong Y coordinates for point4 of orthogonal links. My 2nd mistake was that I called UpdateRoute() which again called GetMidOrthoPosition(). Also AvoidNodes must be set to false.

The GetAvoidRectangle() approach was more tricky as it got called when ever Position() or CalculateRoute() was called. It required carefull tracking of virtual space of subtrees below an if node, especially for nested if nodes.

All in all I think the re-routing approach is the more straight forward way.

Thanks for your effort and help!