I'd appreciate any assistance on this as I feel I have been circling the solution for days.
Here is the scenario:
I have multiple rows of ellipses on a diagram for which the position is persisted to a backing property in my view model.
Using the PenTool, I draw a complex shape on the diagram, whose path is persisted to a backing property in my view model, it is closed and filled using Nonzero.
Upon execution of a command, I collect the selected Ellipses and evaluate whether the Path (which is a PathGeometry from the PenTool) FillContains the positions of the Ellipses.
What I have noticed:
1. The resulting PathGeometry from the PenTool contains a single figure whose StartPoint is often not the position of the of the diagram shape (the CreateShapeGeometry performs some manipulation/normalization within the DrawingService for this.)
2. Regardless of whether I use FillContains or FillContains with detail, the results of examining the ellipse shape points is inconsistent with the visual that is
rendered within the diagram.
Example attached.
Here is the scenario:
I have multiple rows of ellipses on a diagram for which the position is persisted to a backing property in my view model.
Using the PenTool, I draw a complex shape on the diagram, whose path is persisted to a backing property in my view model, it is closed and filled using Nonzero.
Upon execution of a command, I collect the selected Ellipses and evaluate whether the Path (which is a PathGeometry from the PenTool) FillContains the positions of the Ellipses.
What I have noticed:
1. The resulting PathGeometry from the PenTool contains a single figure whose StartPoint is often not the position of the of the diagram shape (the CreateShapeGeometry performs some manipulation/normalization within the DrawingService for this.)
2. Regardless of whether I use FillContains or FillContains with detail, the results of examining the ellipse shape points is inconsistent with the visual that is
rendered within the diagram.
Example attached.
4 Answers, 1 is accepted
0
Robert
Top achievements
Rank 1
Rank 1
answered on 23 Feb 2014, 06:14 PM
And to be clear, I'm looking for ideas or something I'm obviously missing that is specific to how the diagram may be representing the paths at run time or how the bezier segments may be affecting my evaluation.
A real image, rather than the previously attached xml serialized from the diagram:
A real image, rather than the previously attached xml serialized from the diagram:
0
Robert
Top achievements
Rank 1
Rank 1
answered on 24 Feb 2014, 02:51 AM
Having stepped away from it, a thought:
The RadDiagramShape is a container for my geometry and its position is the top left of the template, my visual misrepresents that and I should use the center point of the contained geometry (ellipse), not the shape position.
The RadDiagramShape is a container for my geometry and its position is the top left of the template, my visual misrepresents that and I should use the center point of the contained geometry (ellipse), not the shape position.
0
Robert
Top achievements
Rank 1
Rank 1
answered on 24 Feb 2014, 01:09 PM
Got it.
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.
F1M5.18045311537207E-07,25.5594140041022L30.8641980489095,4.23855251341365E-07L66.5509264439712,25.0771609176824L97.8973770612552,52.5655868436083L82.4652782958231,81.0185189423738L57.3881178019959,108.5069448683L62.6929017526132,135.513117707806L31.828704221749,153.356481905337L7.71604990076136,135.030864621386z)
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
position.
The hole position is also
influenced by its container, however, the visual is drawn offset relative
to it.
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.
5V����a�
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.
F1M5.18045311537207E-07,25.5594140041022L30.8641980489095,4.23855251341365E-07L66.5509264439712,25.0771609176824L97.8973770612552,52.5655868436083L82.4652782958231,81.0185189423738L57.3881178019959,108.5069448683L62.6929017526132,135.513117707806L31.828704221749,153.356481905337L7.71604990076136,135.030864621386z)
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
position.
The hole position is also
influenced by its container, however, the visual is drawn offset relative
to it.
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.
5V����a�
0
Robert
Top achievements
Rank 1
Rank 1
answered on 24 Feb 2014, 01:12 PM
Whoops - caught the buffer of my post to my QA team. :S
Mods - feel free to edit/remove that.
Mods - feel free to edit/remove that.