Datum plane selection object using ID through toolkit

[Ketan_Lalcheta]

Hello

I am having datum plane ID with me in a part file.

With that ID, is it okay to get surface handler using API ProSurfaceInit()? My concern is that I am able to get proper handle for datum plane with above API, but does this ID never crash with Surface ID presents due to part geometry.

My ultimate goal is to find selection object for datum plane using APIs as ProSurfaceInit(), ProSurfaceToGeomitem() and finally ProSelectionAlloc(). This approach is working for surfaces , but Is this proper for datum plane as well?

Thanks in advance!

Regards

Ketan

[FV]

id a ProGeomitem of a surface contained in a datum plane ProFeature could be gotten via ProFeatureGeomitemVisit() with PRO_SURFACE as ProType argument.

[Ketan_Lalcheta]

But is it sure that plane ID found by this way will not get messed up with ID of other surfaces going to be created or already present?

My concern is that I wanna save one of the plane through toolkit code for future use. I am trying to find datum plane ID as surface ID and storing the same in one of the parameter. In future whenever I will reopen the part, I would get that ID from parameter and will initiate datum plane with SurfaceInit using that ID.

Is it safe to do like this or Should I store another thing also to differentiate that ID is not for surface , but it is for datum plane.

[FV · Accepted solution]

Hello all,

Ketan, 

AFAIK, ProGeomitem of the datum plane's ProFeature is persistent as long as ProFeature itself had not been changed.

IMHO, storing ProGeomitem id's in a model parameter is not the best approach - if a user redefines the containing ProFeature it is quite likely the ProGeomitem would change as well and your app will not work anymore. Toolkit's visiting functions are fast and will not degrade your app performance. You'll be probably better off by assigning a parameter to the ProFeature itself or setting a name of this ProFeature. Your app then will look for a feature using either feature name or if a feature has a known parameter... This will take care of feature redefinition. You still would need to set up listeners to watch for a rename event or a parameter deletion/modification.

HIH.

FV.

[Ketan_Lalcheta]

Hi FV,

Appreciate your detailed explanation. Yes, It's a good idea to store values at parameter level itself rather than at model level. 

Thanks a lot...!!