Evaluating FillContains on PenTool PathGeometry

5 posts, 0 answers
  1. Robert
    Robert avatar
    5 posts
    Member since:
    Aug 2010

    Posted 23 Feb 2014 Link to this post

    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.
  2. Robert
    Robert avatar
    5 posts
    Member since:
    Aug 2010

    Posted 23 Feb 2014 in reply to Robert Link to this post

    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:
  3. UI for WPF is Visual Studio 2017 Ready
  4. Robert
    Robert avatar
    5 posts
    Member since:
    Aug 2010

    Posted 23 Feb 2014 Link to this post

    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.
  5. Robert
    Robert avatar
    5 posts
    Member since:
    Aug 2010

    Posted 24 Feb 2014 Link to this post

    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�
  6. Robert
    Robert avatar
    5 posts
    Member since:
    Aug 2010

    Posted 24 Feb 2014 Link to this post

    Whoops - caught the buffer of my post to my QA team. :S

    Mods - feel free to edit/remove that.
Back to Top
UI for WPF is Visual Studio 2017 Ready