Routing does not work properly for elements inside a structured compartment

[xXNicksdaXx]

Hello! I encountered some unexpected behaviour while working with the Manhattan RouterKind inside a freeform structured compartment. In the video you can see the behaviour for the inheritance edge which works properly on the GGraph element. Meanwhile, the other association edge snaps to the top centre of the elements inside the GCompartment (StructuredCompartmentView) in most scenarios. Also, when changing the routing points for the edge, it is correctly received by the server and also set up inside the .notation file, but the client snaps the route back to the top centre of the element.

Although the edges have a different view, they have the same setup. Also, the label at the top of the role elements inside the compartment has a disabled layoutChildFeature set up, but I don't think this is the problem — I encountered similar behaviour for sub elements inside compartments without this label. For some reason I cannot explain, it usually wants to take the top centre of the element …

When investigating the router logic, I could not find a potential source of the issue. Your help is very much appreciated!

[martin-fleck-at]

Hello! I could imagine this has to do with the anchor calculation but it is very hard to tell what is going on without further debugging the actual route calculation. Just out of curiosity, the position of the elements (structured compartment vs classes on root) do not change the behavior, right? Just to make sure the calculation of local vs global coordinates is handled as expected.

[xXNicksdaXx]

The calculation of local vs global coordinates is fine, at least the position of the elements does not affect the edge behaviour negatively.

I checked the anchor calculation as well and the anchor that is returned for both the source and the target element have the correct coordinates, at least the ones I would expect when creating the edge. For this example, it means that the returned anchor for the top left element has the coordinates of the right centre boundary of the node (which would be the preferred side when routing after creating the edge). This is similar to the behaviour of the nodes outside the compartment, which I also checked. The anchor calculation is probably not the issue.

In the ManhattanEdgeRouter, I don't see a way where the anchor points are overwritten — do you have an idea where another source of the problem could be? At some point, the anchor points have to change again, although they shouldn't.

[martin-fleck-at]

Hmm... without actually debugging the code it is really hard to say where the change could happen. You say the router calculates them correctly and sends them to the server correctly as well, the view rendering really shouldn't change the route again but maybe you can look into that.