[CONNECT U12 C++] _OnPostLocate() and returning selected "Child" of a cell

I'm developing a DgnElementSetTool with _OnPostLocate() to return either a single "primitive" (non-complex) element like a Line or LineString OR the currently located sub-element of a cell:

private:	virtual bool _OnPostLocate(HitPathCP path, WStringR cantAcceptReason)
{
    __super::_OnPostLocate(path, cantAcceptReason);
    
    // get the element
	ElementHandle		eh(mdlDisplayPath_getElem((DisplayPathP)path, 0), mdlDisplayPath_getPathRoot((DisplayPathP)path));
    if (eh.GetElementType() == CELL_HEADER_ELM)
    {
    	ElementHandle		ehPart(mdlDisplayPath_getElem((DisplayPathP)path, 1), mdlDisplayPath_getPathRoot((DisplayPathP)path));
    	...
    }
    else
    {
    ...
    }
}

As I move the cursor over a cell, occasionally, the ElementHandle "ehPart" that is created returns false for ehPart.IsValid(). Why does that happen? If the ElementHandle "eh" created from the HitPathCP and tested to ensure it is a cell header, then why does

ElementHandle		ehPart(mdlDisplayPath_getElem((DisplayPathP)path, 1), mdlDisplayPath_getPathRoot((DisplayPathP)path));

sometimes result in an invalid ElementHandle ?

Parents
  • The best hit at a particular location can be generated by the cell header itself and not a component, i.e. path count is 1. For example, it's a group hole (which is a cell) and the hit was to the interior fill as opposed to an edge, etc.

    HTH

    -B

    * You probably want to use -1 for the path index if you want the inner most non-complex component...using 1 you could get a nested cell header, etc.



  • OK - I get what you're saying, but if the returned "best hit" WAS the cell header (or nested cell header), shouldn't the ElementHandle from

    ElementHandle		ehPart(mdlDisplayPath_getElem((DisplayPathP)path, 1), mdlDisplayPath_getPathRoot((DisplayPathP)path));

    still be considered IsValid()? In my tests, that ElementHandle most times returns IsValid()=true, but every once in awhile will return IsValid()=false. I was "testing" by continually moving the cursor across the elements of a non-nested cell. Most times, "eventually" the ElementHandle returned as IsValid()=false. Still wondering why it changes from valid to not valid.

    Now, it so happens that the cell does have filled ellipses, and I was moving cursor across the filled ellipses. So a HitPath may contain items that are not "valid" elements?

  • So a HitPath may contain items that are not "valid" elements?

    No, you aren't checking the path length in your code and are just assuming it's always more than 1...

    Now, it so happens that the cell does have filled ellipses, and I was moving cursor across the filled ellipses.

    This should produce a hit to the ellipse, because the ellipse is outputting the fill. The example I cited is one where the complex header is outputting the fill as the closed region is formed from open boundary components, i.e. no single component is filled.

    Fill is just one example, I don't know your specific geometry, snap mode, etc. I'm just pointing out that a path that only references the cell header is perfectly valid. If you require a component and the path doesn't identify one you should just return false from _OnPostLocate to reject the hit for your tool.

    -B



    Answer Verified By: Bruce Reeves SRNS 

  • OK - Just went back and tried my "test" with the initial value of "1" for

    ElementHandle		ehPart(mdlDisplayPath_getElem((DisplayPathP)path, 1), mdlDisplayPath_getPathRoot((DisplayPathP)path));

    I also traced the path length and the "type" of the element that locate is returning to _OnPostLocate(). When my code freezes up, I have moved the cursor over a cell, so 

    ElementHandle		eh(mdlDisplayPath_getElem((DisplayPathP)path, 0), mdlDisplayPath_getPathRoot((DisplayPathP)path));

    gives me the CELL_HEADER that the cursor is over, but the path length is only 1, so when I try to create the "eehPart" ElementHandle by grabbing HitPath index 1 (the second item) - it crashes because there is no index=1 component. Now I see why it crashes every once in awhile. As you say, I can test the HitPath length and return false, when the located element is complex AND the length is 1.

    But, your recommendation of using -1 for the index, for my needs in this case, is probably the best recommendation.

    Once again, that you for your insights and explanations !!

Reply
  • OK - Just went back and tried my "test" with the initial value of "1" for

    ElementHandle		ehPart(mdlDisplayPath_getElem((DisplayPathP)path, 1), mdlDisplayPath_getPathRoot((DisplayPathP)path));

    I also traced the path length and the "type" of the element that locate is returning to _OnPostLocate(). When my code freezes up, I have moved the cursor over a cell, so 

    ElementHandle		eh(mdlDisplayPath_getElem((DisplayPathP)path, 0), mdlDisplayPath_getPathRoot((DisplayPathP)path));

    gives me the CELL_HEADER that the cursor is over, but the path length is only 1, so when I try to create the "eehPart" ElementHandle by grabbing HitPath index 1 (the second item) - it crashes because there is no index=1 component. Now I see why it crashes every once in awhile. As you say, I can test the HitPath length and return false, when the located element is complex AND the length is 1.

    But, your recommendation of using -1 for the index, for my needs in this case, is probably the best recommendation.

    Once again, that you for your insights and explanations !!

Children
No Data