I’m having trouble displaying Link Labels properly when a link Route specifies Routing=“AvoidsNodes”. I’m using LinkPanel.Orientation=“Along”.
I have a LinkPanel with a LinkRoute inside it. If I do not specify the Routing, I get labels like this:
But if I add Routing=“AvoidsNodes”, my labels look like this:
Why is this happening and, more importantly, what can I do to fix it?
Thanks,
Bob
I’m guessing that with AvoidsNodes routing there happens to be a very short segment at the middle of the route, which appears to be vertical.
I suggest you use a different Orientation, perhaps None.
Hi Walter,
Although the pictures I posted showed text as the link labels, my actual application is to use an image that looks sort of like an arrowhead. It really needs to be oriented “Along” to look right.
However, I’m not convinced that there’s a vertical segment there. Consider this image:
Surely the first and last links don’t have vertical segments at the labels’ positions.
Well, either “Along” or one of the other “along-like” orientations but with a +90 or -90 or +180 degree turn: “Plus90”, “Minus90”, “Opposite”.
Hi Walter,
The “along-lile” orientations also exhibit problems. Plus90 will show the label correctly in a straight-line link, but will mess up (even accounting for the rotation) in more complex routes.
Check out this image from the Link Demo of GoWpf Demo:
The first link’s “Mid” label is oriented wrong. Sure enough, its orientation is AvoidsNodes. This is the unmodified demo; you should be able to reproduce it.
Is this a bug in GoXam for WPF?
The reason that that text is vertical is because the middle segment is vertical.
You can see what happens when you reshape the link.
I don’t think it’s just because the Route.Routing is “AvoidsNodes” – it’s also true when it’s “Orthogonal”.
If you really want to customize the angle, you can override LinkPanel.ComputeAngle.
That’s the method that looks at the value of the attached Orientation property and decides what angle to return.
Hi Walter,
The middle segment is vertical? On the first, thick green link between the dark red shape and the yellow shape? Yes, there’s a vertical segment in that line, but the “Mid” label is not positioned anywhere near it. Surely, it makes sense for that “Mid” label to be horizontal rather than vertical, given where it’s positioned.
But if there really is a vertical segment underneath that “Mid” label, then it’s either a vertical segment with a zero height - in which case, why does it exist? - or it’s a vertical segment with a height too small to be noticeable - in which case why isn’t the first vertical segment in that line the correct height so that no other verticals are needed?
Yes, the “Mid” label is not positioned adjacent to the vertical segment. I’m not sure why.
But yes, the general problem is that that vertical segment might be of zero height because both adjacent horizontal segments have the same Y value. It exists for simplicity in calculations, which are complicated enough as they are.
I wonder if specifying the go:LinkPanel.Index might help you.
Hi Walter,
I assumed the “Mid” label is not positioned adjacent to the vertical segment because it’s not supposed to be. It’s supposed to appear in the middle of the link, and the vertical segment is not near the middle.
What would I do with the LinkPanel.Index? Isn’t the number of segments variable, since each bend in the line requires a new one? I would need to know how many segments there are, their direction and length. Is there a way for me to get that segment information?
If I could get that info, I would also be able to confirm whether there’s really a zero height vertical segment.
I don’t want to push you, but do you see consider this a bug?
Thanks,
Bob
The Route.PointsCount tells you how many points there are. Assuming it’s not Bezier, the count-1 is how many segments there are. And you could override ComputeMidPoint and ComputeMidAngle, if you don’t want to specify the particular segment index and other attached segment properties.
We’ll take a closer look at this problem.
Interesting. It appears that there are always 5 segments and there is, indeed, a zero length segment in the middle of straight links.
When an “along-like” label is attached to a zero length segment, it seems to me you need a more sophisticated algorithm to determine the orientation.
Hi Walter,
I’ve been thinking about doing my own calculation to figure out the right orientation of the label. Is there an event I can hook so I know when a link’s path has changed?
Thanks,
Bob
If you don’t set the go:LinkPanel.Index property, you just want to consider overriding ComputeMidPoint and ComputeMidAngle. Their values are automatically cached, and those methods will get called again when needed.
In looking at the code, the reason for the mid label being positioned away from the middle segment is so that it is closer to the actual midpoint of the route. People had complained that the midpoint of the middle segment could often be very far from the geometric midpoint of the route. I suppose we could improve the angle to be dependent on the segment where the midpoint is actually calculated.
We have improved ComputeMidPoint and ComputeMidAngle for version 1.3.
When will 1.3 be available?
We’ll come out with a beta after Silverlight 5 is released; I expect the official 1.3 can come out soon thereafter.