PPR Hub

What You Will Learn With This Use Case

This use case is intended to illustrate how to create new feature StartUps in a new feature catalog. These StartUps are actually feature definitions, or prototypes, that are then retrieved in a working document and instantiated as features. These particular StartUps are generally used in the CAAPstIntegrateNewFeatures use case modules in order to demonstrate integrating new features in the basic CATIA mechanisms within a Product document. You should already be familiar with the CAAPstIntegrateNewFeatures use case article [1] in order to more easily understand the context of this use case.

[Top]

The CAAPstINFBuildCatalog Use Case

The CAAPstINFBuildCatalog is a use case that is part of the CAAPstIntegrateNewFeatures use case defined in the CAAProductStructure.edu framework that illustrates the integration of ObjectSpecsModeler framework capabilities.

[Top]

What Does the CAAPstINFBuildCatalog Use Case Do

This use case illustrates creating new StartUps  in a feature catalog. The StartUps are created "from scratch", i.e., they do not derive from any existing StartUps and do not, therefore, inherit any data or behaviors at all. 

Here is an image of the contents of the feature catalog containing the "StartUps" that will be created in this use case:

• "CAAPstINFRoot" represents the parent node that will aggregate all the other features. Its unique attribute contains a list of components, in other words, a list of the features that it aggregates.
• "CAAPstINFPoint" is a feature representing a 3D geometrical point. Its attributes contain the values of the x, y and z coordinates of the point.
• "CAAPstINFLine" is a feature representing a 3D geometrical line. Its attributes contain references to the two points of type "CAAPstINFPoint" that define the line.
• "CAAPstINFWire" is a feature representing one or several inter-connected 3D geometrical lines. Its attribute contains a list of at least two "CAAPstINFPoint" features that define the wire.

[Top]

How to Launch the CAAPstINFBuildCatalog Use Case

See the section entitled "How to Launch the CAAPstIntegrateNewFeatures Use Case" in the "Integrating New Features in a Product Structure" use case for a detailed description of how this use case should be launched.

The particular part of the use case described in this article is launched by executing the following command:

    mkrun -c "CAAPstINFBuildCatalog CatalogStorageName"

[Top]

Where to Find the CAAPstINFBuildCatalog Code

The CAAPstINFBuildCatalog use case is made of one module, CAAPstINFBuildCatalog.m,  found in the the CAAProductStructure.edu framework and containing a single source program, CAAPstINFCatalog.cpp:

where InstallRootDirectory is the directory where the CAA CD-ROM is installed.

[Top]

Step-by-Step

There are four logical steps in CAAPstINFBuildCatalog:

1. Creating the Feature Catalog
2. Creating StartUps in the Feature Catalog
3. Adding Attributes to StartUps
4. Saving the Feature Catalog

We will now comment each of these sections by looking at the code. 

[Top]

Creating the Feature Catalog

...
CATICatalog *piCatalog = NULL;
CATUnicodeString storageName = argv[1];
rc = ::CreateCatalog(&storageName, 
                     &piCatalog);
...
// Add a client identification to the catalog.  This is a mandatory step. 
CATUnicodeString clientId("CAAPstINFClientId");
rc = piCatalog -> SetClientId(&clientId);
...   

Use the CreateCatalog global function to create a new feature catalog. The arguments of this function are:

• storageName - this is the entire pathname and name of the catalog, passed as an argument to the use case. This parameter is the same as the one passed to the method that saves the catalog.

• piCatalog - this is the returned CATICatalog pointer to the new catalog that has been created.

In order to protect your catalog from unwanted access, you must also assign a client ID to it. This ID is needed in order to open the catalog to retrieve StartUps from it. The client ID is set using the SetClientId method of CATICatalog and passing a CATUnicodeString parameter representing the client ID.

[Top]

Creating StartUps in the Feature Catalog

...
CATBaseUnknown *pRootSU = NULL;
CATUnicodeString rootSUName("CAAPstINFRoot");
CATUnicodeString rootSUType("CAAPstINFRoot");
rc = piCatalog -> CreateSUInCatalog (&pRootSU,
                                     &rootSUName,
 	     	                     &rootSUType,
				     "CATISpecObject");
...

// Get a CATISpecObject handle on the CAAPstINFRoot StartUp

CATISpecObject *piRootSU = (CATISpecObject*) pRootSU;
...   

A new StartUp is created using the CreateSUInCatalog method of CATICatalog. This method takes the following arguments:

• pRootSU - this is the returned StartUp that is created in the catalog.

• rootSUName - this is the name of the new StartUp to be created.

• rootSUType - this is the type of the new StartUp to be created.

• "CATISpecObject" - this is the interface that will support this StartUp.

Once the StartUp has been created, the retrieved CATBaseUnknown pointer to it can directly be cast to a pointer of the requested interface.

The above code example shows you how the "CAAPstINFRoot" StartUp is created. The other three StartUps, "CAAPstINFPoint", "CAAPstINFLine" and "CAAPstINFWire" are created in exactly the same way.

[Top]

Adding Attributes to StartUps

...
CATUnicodeString listComp("ListOfComponents");
CATISpecAttribute *piListComp = piRootSU -> AddAttribute(listComp,
                                                         tk_list(tk_component),
                                                         sp_IN);
...   

A new attribute of a StartUp is created using the AddAttribute method of CATISpecObject. This method takes the following arguments:

• listComp - this argument is a CATUnicodeString variable representing the name of the new attribute.

• tk_list(tk_component) - this is the type of attribute to be added. In this case, the attribute will contain a list of tk_component type objects, in other words, aggregated features.

• sp_IN - this is the "quality" of the attribute: it is used during the Update process to determine whether this feature is to be re-built or not.

The attributes of the other StartUps are added the same way, except that they are of type tk_double in the case of the "CAAPstINFPoint" feature, tk_specobject in the case of the "CAAPstINFLine" feature and tk_list(tk_specobject) in the case of the "CAAPstINFWire" feature.

Remember to release the CATISpecAttribute pointer returned by this method. Also, remember to release the CATBaseUnknown pointer to the StartUp when it is no longer needed.

[Top]

Saving the Feature Catalog

...
rc = ::SaveCatalog(&piCatalog,
		   &storageName);
...   

The new feature catalog is saved using the SaveCatalog global function which takes the following arguments:

• piCatalog - this is the CATICatalog pointer to the new catalog that was created previously.

• storageName - this is the pathname and name where the new catalog is to be stored. This parameter must correspond to the one indicated for the CreateCatalog method.

Remember to release the CATICatalog pointer as it will no longer be needed.

[Top]

In Short

The CAAPstINFBuildCatalog use case has shown you how to create a new feature catalog using the CreateCatalog global function, how to create new StartUps using the CATICatalog::CreateSUInCatalog method, how to add new attributes to a StartUp using the CATISpecObject::AddAttribute method and how to save the new catalog using the SaveCatalog global function.

[Top]

References

History

Copyright © 2002, Dassault Systèmes. All rights reserved.