Getting Started with Your Own Features

Technical Article

Abstract

This 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.

Introduction

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.

Designing Your StartUps

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.

Data Model

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:

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.

Behavior Model

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.

Creating, Storing and Activating Features

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 Container

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.

Feature Creation

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:

Feature Loading

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 Short

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.

References

[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

History

Version: 1 [Nov 2007]Document created