Getting Started with Your Own Features |
| Technical Article |
AbstractThis article will give the major guidelines on how to get started with your own features: starting from the design of the StartUps and ending with their instantiation. |
You have already read the "Feature Modeler Concepts" [1], know how to use Dassault Systemes supplied features [2] but decided to create your own features from scratch. This article will present an overview of the essential steps.
We will first start with the design of the StartUps by explaining how the data model is created and how behavior is attached. Next we will show how these StartUps are instantiated into features, ready for use by run-time code.
In the "Feature Modeler Concepts" article [1], we have explained how features are created: by instantiating their templates called StartUps. A StartUp is defined by its data model and its behavior model. The data model consists of its attributes while the behavoir model is the set of interfaces implemented.
The data model of the StartUps is defined using the OSM language [3]. Suppose that we want to model a point:

It can be defined in OSM as:
...
feature CAAPoint #startup {
double x
double y
double z
}
...
|
Things that you should keep in mind when designing your StartUps:
#inheritability(caa) facet [3]
in OSM:feature CAAPoint #startup #inheritability(caa) { |
CAAPoint feature could be derived from the
GeometricalElement3D as:feature CAAPoint #startup GeometricalElement3D@`MechMod.feat` { |
You can define any number of features in an OSM file to suit your application needs. Once this OSM file is deemed complete, it can be used to create/update a StartUp catalog [5].
Each catalog is created with a client ID supplied by you. This client ID is required whenever the catalog is updated and specified in the code to access the StartUps.
The newly created/updated catalog must then be put in the run-time view where the Feature Modeler expects it to be. We now have StartUps with their data fully defined, it is time to attach behavior to it.
Interfaces are implemented on StartUps via its late type which happens to be
its name. There exists a set of interfaces that are inherited by all features:
CATISpecObject, CATISpecAttrAccess to name
a few. Depending on your application, new interfaces can be added and/or
existing interfaces can be reimplemented.

Suppose that we would like to implement the CAAIPoint interface
on our CAAPoint StartUp, with the implementation class
CAAEPoint. The source file of the CAAEPoint class must
contain the following code [8]:
...
TIE_CAAIPoint(CAAEPoint);
CATImplementClass(CAAEPoint,
DataExtension,
CATBaseUnknown,
CAAPoint);
... |
The CAAIPoint interface has a GetCoordinate
method to retrieve the point location, it would be implemented as:
...
HRESULT CAAEPoint::GetCoordinate(double& oX, double& oY, double& oZ)
{
CATISpecAttrAccess *piAttrAccs = NULL;
HRESULT rc = QueryInterface(IID_CATISpecAttrAccess, &piAttrAccs);
...
CATISpecAttrKey *piXkey = piAttrAccs->GetAttrKey("x");
...
oX = piAttrAccess->GetDouble(piXkey);
... |
The above example shows how the x, y and z attributes of the
CAAPoint feature is retrieved with the CATISpecAttrAccess
interface. You might notice that the attribute is not specified by name
but with the CATISpecAttrKey interface.
To make your features fully integrated in CATIA, you need to implement several interfaces. The whole process is described in the "Integrating Applicative Features in a Product Structure" article [8]
Now you that you have a StartUp complete with its data and behavior, let's see what needs to be done before it can be instantiated.
When a StartUp is instantiated into a feature, a container must be specfied for its storage. Derived features get stored in the same container as the features they are derived from. For a DS derived feature, there is no need to create/set up the container. If your feature derives from nothing, then an applicative container must be created/set up.
In this section, we will introduce the applicative container and the interfaces that can be implemented on it.
Applicative containers [6] are created in CATDocument and are identified by its name. This name also happens to be the late type on which interfaces are implemented. The CAA naming rules [4] therefore apply.
The most important point for an applicative container is
that its super type must be CATFeatCont.
Failing that, the container will not behave as expected.
The features of an applicative container can only retrieved if the correct client ID is supplied. The one that was specified when the StartUp catalog was created.
Even though StartUps can be instantiated thanks to the CATOsmSUHandler
class, a more appropriate way to do this is to implement a factory
interface on the container. This would hide implementation details from the
final feature user.
Suppose that we have defined the CAAIPointFactory
interface to create our CAAPoint features. The Create
method of the CAAEPointFactory implementation class could be
defined as follow:
...
HRESULT CAAEPointFactory::Create(CAAIPoint **oPoint)
{
CATBaseUnknown *piContainer = NULL;
rc = QueryInterface(IID_CATBaseUnknown, &piContainer);
...
CATOsmSUHandler pointSU("CAAPoint", "CAAClientID");
CATISpecObject_var spPoint;
HRESULT rc = pointSU.Instantiate(spPoint, piContainer);
...
rc = spPoint->QueryInterface(IID_CAAIPoint, (void **) oPoint);
return rc;
}
... |
Note:
CATBaseUnknown interface which is required by the
StartUp instantiation.
Now that your features are created and stored inside containers, there is one
thing left to be handled: their loading. This is done by implementing the
CATInit interface on the container. This is normally taken care
by the container's owner. Which means that unless your features are derived from
the DS ones, you will need to implement CATInit [6].
In this article, we have outlined the essential steps to define your own features: design the StartUps, implement their behavior, implement interfaces on the container that will hold the features.
| [1] | Feature Modeler Concepts |
| [2] | Getting Started with DS Features |
| [3] | Modeling StartUps |
| [4] | CAA C++ Naming Rules |
| [5] | Managing StartUp Catalogs |
| [6] | Understanding Applicative Container |
| [7] | Creating Interfaces |
| [8] | Integrating Applicative Features in a Product Structure |
| Version: 1 [Nov 2007] | Document created |