Problems with GoLink

Before I ask you my questions, I would like to describe my project requirements briefly.
Our view can have several types of objects on it.
Those objects can be connected with each other with their conectors.
The connectors implemented as GoLink descendants (It is MyLink class in the attached example).

Every object must be aligned by a view grid with its center.
Every connector must be orthogonal, its every point must be aligned by a view grid.
I’ve prepared a simple example to illustrate my questions. To simplify the example I didn’t include objects that must be connected with connectors, there are only links (connectors) which can be connected with each other by relinking.
To be connected, the links have ports at the ends. You can drag one of a connector end to
another connector end to connect them. (To show ports, define conditional compilation symbol SHOW_PORTS for the whole project or only just for MyLink.cs).

Example link:

  1. Why do the ends of MyLink have offsets? Look at the pic1.png. I expect the first and last
    connector point coords are aligned by grid, but they are not. There is offset of 0.5. Ports have no size. Because of the offset I have a bit curved lines that connect objects and it looks not very good.

  2. How can I achieve every connector (not only its ends) point to be aligned by grid? I need it when a connector is moving or relinking.
    This issue illustrated by pic2.png

  3. When I move any intermediate connector point, sometimes I have situation when a link segments are not orthogonal to each other (pic3.png). How can I retain orthogonality moving intermediate connector points?

P.S. I use GoDiagram My company has OEM License. I can send you the license information if needed.

  1. Links draw their first segment in the “From” or “To” direction, and the length of that first segment is defined by GoPort.EndSegmentLength. You can set that to zero.

  2. GoLink routing doesn’t know about grids. Probably the simplest thing to do here is override GoLink.CalculateRoute, call the base method and then “fix up” (i.e. snap) the midpoints to the grid.

ok… a weak first try here:

public class GoSnapLink : GoLink

public override void CalculateRoute()

  for (int i = 2; i < this.PointsCount-2; i++)
    PointF pt = this.GetPoint(i);
    float grid = 35.0f;
    float mod = pt.X % grid;
    if (mod < grid/2)
       pt = new PointF(pt.X - mod, pt.Y);
    else {
      pt = new PointF(pt.X - mod + grid, pt.Y);
    this.SetPoint(i, pt);


note I’m only handling adjusting the X of the vertical segment to be aligned. And the link is aware of the
grid size, because the link doesn’t have easy access to the GoView. (So I cheated.)

so… it would have to be a lot smarter than this, but this is a start. You might have to add points to get the horizontal links aligned if your ports aren’t aligned with the grid.

(this also doesn’t work if you resize (drag) bits of the link.)

  1. Is that a GoLink or a GoStroke? GoLink should handle orthognal resize. See the Processor sample, it lets you add new points to the orthognal link.

Hello, Jake!
Thank you for your answer!

  1. Yes, I know about the GoPort.EndSegmentLength property, but it is not that I need. I meant the first and last connector points are not aligned by grid. Watch at the picture bellow:

    You can see, that there is the first point has coords X=399.5, Y=225. My question is - Why do the X value of the first point has strange value 399.5? I expect it should be equal to 400. Because of this little offset I have a bit curved lines on a view. How can I avoid this issue?
    By the way, if I set the GoPort.EndSegmentLength to zero, the arrow at the end will desapear. I want the arrows to be visible. Is there any way to get rid of the segments at the ends of GoLink and having the arrows visible?

  2. I have worked around this problem using similar approach, but I passed GoView.SnapPoint method as a delegate to GoLink and used it to align intermediate points by grid. I thought may be there is something out of box to solve the problem:
    private Func<PointF, GoObject, PointF> _snapPointMethod;

         public override void CalculateStroke()
             if (_snapPointMethod != null)
                 for (int i = 2; i < this.PointsCount - 2; i++)
                     PointF pt = _snapPointMethod(this.GetPoint(i), this);
                     this.SetPoint(i, pt);
  3. It is GoLink of course. I forgot to mention, that when we add an extra point on a link (in my example you can add a point with double click on it), I set GoLink.AdjustingStyle = GoLinkAdjustingStyle.End. It is necessary to not lose added points when a user relinking a link. If I don’t do that (GoLink.AdjustingStyle = GoLinkAdjustingStyle.Calculate), each added point will be removed after next CalculateStroke call.
    My problem is to give a feature to users to add extra points, retain ones after relinking or other operations, and the most important aspect is that a link must be always orthogonal and its points must be aligned by a grid.
    Although a link has its Orthogonal property set to true, when I move its intermediate points, I can get not orthogonal link like at the picture below:

I’ve watched at the example (Processor sample). It’s exactly that behavior I need! Maybe I don’t understand something, but it seems the behavior I’ve described before is accessible out of box? But then why I can move intermediate points in not orthogonal way? Maybe I’ve not set some property properly, or do something wrong… Could you reproduce that incorrect behavior and point me out where I’m mistaken.

Here is my updated example is rar file:

Thanks in advance.

Good morning!

  1. I’ve tried to reproduce the same behavior in Processor sample but I couldn’t. But in my attached example the wrong behavior can be reproduced easily.

Any ideas?

P.S.: The first question is still actual for me.

Try connecting the GoLink to a node on each end.

I think what you are seeing in Q 1 (pic4.png) is the LineCap offset. Pointy arrowheads look weird if you draw the link to the last pixel.

Hello, Jake!

I tried to do you had said but the result is the same (watch at the pic6.png)

I’ve created the GoBasicNode on each end of the GoLink and set FromPort and EndPort to those nodes Port property.
You can see the result in my attached example:

Did I do exactly that you had meant in your answer?

OH! Look at what Processor does in “Add Point to Link” for Orthogonal links.

Thanks! It works!

About Q.1: I overcame that issue adjusting last and penultimate points forcibly by grid in Stop method of the GoToolRelinking descendant.

Hello, guys!

I discovered a bug in you product. I had thought that a bug somewhere in my code, but it isn’t. I downloaded the latest version of GoDiagram ( and used example Processor as a starting point. The bug consist of the foolowing (look at the picture bellow)

The orthogonality can be easily broken.
There are steps I made to achieve that:

  1. I added only 4 additional lines of code in the sample project (method Form1.Form1_Load):

    // initialize the view
    goView1.NewLinkClass = typeof(FlowLink);
    // My lines
    goView1.GridLineColor = Color.Gray;
    goView1.GridStyle = GoViewGridStyle.Line;
    goView1.GridSnapResize = GoViewSnapStyle.Jump;
    goView1.GridSnapDrag = GoViewSnapStyle.Jump;

    I did it because It’s easier to reproduce the bug when we have lines aligned by grid. When we have no grid snapping to reproduce the bug is very difficult (but possible).

  2. I added two objects at the GoView (Start and Finish)

  3. I linked the two with the GoLink

  4. After I aligned the middle segment by the grid and inserted a point

  5. Then I move the point down along the segment it belongs to and the orthogonality breaks…

We have a project that built on GoDiagram and that behavior is unacceptable for us.

How can we fix that behavior and retain the orthogonality?

I’m looking forward the answer.
Thanks in advance!

using the right-click context menu “insert point” ?

Yes, I inserted the point using the context-menu.

Well, I pasted in your changes to grid settings in my copy of the sample, and I don’t see a problem.

Can you email me your full sample?

Of course, Jake.
Here is the separated sample:

Here is a recorded video sample that reproduces the bug:

can you upload a .zip file? Sorry, but I don’t have the time to spend reviewing RAR utilities.

If you want you can use code from samples.
There are no differences other than that I provided already (4 lines of code)

Also I can provide a patch to the sample project “Processor4”

Here comes a zipped project with those 4 lines added.

Also we re-recorded the video of the bug
(comes as webm, can be open in chrome)

I hope these all stuffs will help you to reproduce the bug at last!

Jake, have you reproduced the bug?!

Guys, are you there?!
Didn’t you forget about my question?

No ideas?!