Solid Edge ST has just been released and I'm trying to make my old code work with it. However, I have the following problem:
ST can open Part document which are either of type igPartDocument or igSyncPartDocument;
There are now two "PartDocument" types:
SolidEdgePart.PartDocument or SolidEdgePartSync.PartDocument.
What is the best way of making my code work with either type without duplicating every function: i.e. one with "using SolidEdgePart" and another "using SolidEdgePartSync"?
Thanks for any pointers
Posted by: Chahe Adourian
Post date: 9/11/2008 3:26:00 PM
When opening a document, you should reference the variable as a SolidEdgeFramework.SolidEdgeDocument and check it's Type property. See the DocumentTypeConstants enumeration for possible types.
Posted by: Jason Newell
Post date: 9/15/2008 4:41:04 AM
I know about the two types: SolidEdgePart and SolidEdgePartSync.
The problem is the following;
I have written all my code to work for SolidEdgePart. Say for example
Now If I get an SolidEdgePartSync.PartDocument, I can certainly not use the same function; I was wondering if there's a supertype or another interface that can access both types (Sync Type PartDocument, or old PartDocument) equally well.
I've looked and found nothing of the sort, so I assume there is no common interface. Which means I have to duplicate my FunctionA and create something like myFunctionSyncA(SolidEdePartSync.PartDocument partDoc) ....
thus duplicating my code.
Generics don't seem to be a solution in this case.
I think the only way forward is duplicating my code to handle each case separately.
Posted by: Chahe Adourian
Post date: 9/15/2008 2:39:01 PM
There is a base interface that can help out. It is SolidEdgeDocument. The interface contains all that is common to every document in Edge. Some 3d controllers use that type and so do some doc management clients.
Unfortunately the modeling environments of part and sync part diverge so much that no common interface was deemed useful enough.
However many of the APIs in part exist in sync part and calls to them are handled relatively well but the doc objects (interfaces) are different so you pretty much have to keep the two data types in your code. Mostly this is limited to creation of model features but once created modifying the features is not the same as sketch data is consumed in sync part. Also I believe a lot of the collection objects can be obtained from a sync doc api but the collections will simply be empty. Regions and faces rule in sync while sketches and features rule in "classic" part.
If you are using C++ you might code up some template that you instantiate with whichever doc interface you have obtained and use the template for common functionality but there will never be a one-to-one matchup between the two types (which is why there are two types to begin with).
Posted by: R.D. Holland
Post date: 9/18/2008 10:03:25 AM