3D PLM PPR Hub Open Gateway

Overview of Basic CATIA Behaviors

This document takes into account a certain number of basic CATIA behaviors that need to be considered whenever you create a new feature. This section describes each of them.

• Cut/Copy/Paste/Delete.

In order to have access to CCP and Delete operations, these options must be selectable in the Edit or contextual menus. These options are filtered by the CATICSOFilter interface. This means that, depending on the context (workshop, to be precise), this interface may already have been implemented by the UIActive object and some operations may have been disabled. By default, if the CATICSOFilter interface has not been implemented on the UIActive object, all operations are enabled. In a Product document, the CCP and Delete operations have been disabled on non-Product features. This means that the new feature must itself implement the CATICSOFilter interface in order to enable CCP and Delete operations. In a Part document, since the CATICSOFilter interface has not been implemented, you should not have to consider this interface. 

The CCP and Delete operations themselves are managed by the CATICutAndPastable and LifeCycleObject interfaces. These interfaces are implemented on selectable CATIA features.

• Editing.

Editing a feature occurs through a dialog box that is displayed upon either double-clicking on the feature or using the right button of the mouse on the feature to display its contextual menu, then selecting the "Define" command in the sub-menu section. The dialog box contains all of the modifiable attribute values currently valid for the selected feature. This editing capability is managed by the CATIEdit interface. When the CATIEdit interface is implemented on a feature, it is also possible to further expand the contextual sub-menu with new commands by implementing the CATIContextualSubMenu interface. See the "Editing Objects" use case found with the ApplicationFrame framework documentation.

• Generic Properties.

The CATIProperty interface manages the ability to add, retrieve and delete generic properties defined on features.

• Geometrical Visualization.

A feature's geometrical visualization is managed by any C++ interface deriving from CATIVisu: CATI3DGeoVisu, CATI2DGeoVisu, etc. You must at least implement one visualization interface to display the newly features. Note, that it is possible to implement several interfaces deriving from CATIVisu for the same StartUp [1]. 

A feature's graphical properties are managed by the CATIVisProperties interface. You should implement it to associate graphical properties to the features [2].

The CATIModelEvents interface manages sending event notifications in the case where the visualization of the feature has been modified and needs to be refreshed. The implementation of this interface is not mandatory, but strongly recommended, because it is essentially used for performance reasons in order to force the visualization of only the part of the geometry that has been modified instead of forcing a re-visualization of the entire geometry.

• Persistency of Feature Name.

The CATIAlias interface manages the persistency of a feature's name. A default implementation of this interface does exist, the GetAlias method is based on the GetDisplayName method of the CATISpecObject interface, and the SetAlias method modifies the default external name. BUT the default SetAlias implementation does not manage the persistency, it means that you must implement CATIAlias to keep a user name. You can refer to the article entitled "Feature Modeler Overview" for details about the StartUp internal and external names [3].

To implement CATIAlias , you should respect the following recommendations:

• Define a string attribute to store the object's applicative internal name ("AppKey").
• The external name returned by GetAlias must be computed (*) with:

• "AppKey", This attribute enables you to look for a NLS string thanks to your own reference name, and not with the internal name of the StartUp.
• an NLS resource file,
• and if needed with GetDisplayName of CATISpecObject (for example to retrieve the index value).

(*)Never store a name that can be displayed in a NLS context. 

• Publication of Knowledge Parameters.

The CATIParmPublisher interface allows the publication of a feature's parameters.

• Replace.

The CATIReplace interface allows replacing the valuation of one attribute by another object. 

• Specification Tree Visualization and Navigation.

Visualizing a feature in the specification tree and enabling further navigation of the feature itself is managed by the CATINavigateObject interface. This interface is implemented on all natively-defined CATIA features, i.e., features defined in applications provided by Dassault Systemes. Its methods return the name of the feature and a list of its children. When a feature is added to the specification tree under an existing node, that parent node must be capable of listing it as its child. The feature itself must also be capable of listing any of the features it may be pointing to. The CATINavigModify interface allows a specific icon to be specified for a given feature. You can use the methods of CATIRedrawEvent to force a refresh of the specification tree whenever a modification has been made. See the ObjectModelerBase use case entitled "The Object Navigator" [4] for a detailed example of the navigation process.

• Update.

The CATIBuild interface allows the re-calculation of a feature's results as part of the general update process whose execution is triggered by the Update method of CATISpecObject. See the ObjectSpecsModeler use case entitled "The Build/Update Mechanism" for a detailed example [5].

In Short

This section summarizes in table form the interfaces to taken into account when a new feature is defined "from scratch", i.e., not derived from any existing Dassault Systemes feature. Here are the explanations of the different CAA interface implementation possibilities based on the last two columns of the table:

• Existing Default Implementation  AND Possible: This means that an existing default implementation of the corresponding interface is available but you may override it if the specificity of your feature requires it.
• No Existing Default Implementation  AND Mandatory: This means that no default implementation of the corresponding interface is available and that the implementation of the interface is mandatory in order for the feature to access this behavior.
• No Existing Default Implementation  AND Possible: This means that no default implementation of the corresponding interface is available but that it may be possible to implement the interface in order for the feature to access this behavior. 

 

Behavior	Interface	Existing Default Implementation (Yes/No)	CAA Implementation (Mandatory/Possible)
Cut/Copy/Paste/Delete	CATICutAndPastable LifeCycleObject CATICSOFilter	Yes Yes No	Possible Possible Possible
Editing	CATIEdit CATIContextualSubMenu	No No	Mandatory Mandatory
Geometrical Visualization	CATI3DGeoVisu CATIVisProperties CATIModelEvents	No No No	Mandatory Mandatory   Possible
Persistency of Feature Name	CATIAlias	Yes	Mandatory
Publication of Knowledge Parameters	CATIParmPublisher	No	Mandatory
Replace	CATIReplace	No	Mandatory
Specification Tree Visualization and Navigation	CATINavigateObject CATINavigModify	No No	Mandatory Mandatory
Update	CATIBuild	No	Mandatory

[Top]