Posted 24 Feb 2014
Link to this post
Real problem was working sixteen days straight for 12 or more hours a day... but I digress.
An explanation for those interested, two things were happening:
1. The path was relative to the RadDiagramShape content control. So, any point evaluation needed to include the position of that shape as an offset to align the shape position to the path expression. For example, the PenTool shape was at 10,10 but the path is relative to the control, starting at 0,0 for argument sake.
2. As I mentioned last night, the position of the shape being evaluated for intersection has a position that represents the top left. The visual image actually is also offset within the RadDiagramShape, so, needs to be offset too.
It's nice to have a solution, but I'll admit the real problem was being tired. :)
Here is my
explanation (I'll post to the Telerik folk, they didn't have an answer, but in
my tests this worked pretty good.) Two things are happening.
The green area you see above
is expressed as a path statement with origin included (e.g.
The instructions basically describe how to draw the shape. Fill, non-zero,
start at 0.000000518, 0,000000423, draw a line to 30.864, 0.blah blah)
Anyway, when I was evaluating the containership of the position of the
hole, I assumed the path statement represented the visual on the canvas -
and while it did, the trick was that that image exists within a container
that has position, thus the points on the path are relative to that
position and the hole position needs to be offset by the container
The hole position is also
influenced by its container, however, the visual is drawn offset relative
In the end, I grab
the hole position, offset it by the inverse of the initiation area position and
then offset the resultant position by the size of the ellipse radius. So far,
even fairly complex areas are resolving correctly (I write out to Debug View/Trace
Log the determination.) I'll check this in and see what you guys think.