3D PLM PPR Hub Open Gateway

Introduction

Documents are often transferred between clients and sub-contractors. But how are the features managed in the retrieved document when the application code and feature catalog do not accompany this transfer? This article intends to answer this question by analyzing a number of common basic behaviors on features created "from scratch" as well as on features derived from other existing features when the application code and catalog are available as compared to when they are not available.

[Top]

Overview of Basic CATIA Behaviors 

The basic CATIA behaviors analyzed in this article are:

• The display of the feature in the specification tree: This behavior 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. If a new client-defined feature is created in the document, it must implement the CATINavigateObject interface in order to correctly appear in the specification tree. 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 be capable of listing any of the features it may eventually be pointing to.
• The visualization of the feature's geometry: This behavior is managed by any C++ interface deriving from CATIVisu: CATI3DGeoVisu, CATI2DGeoVisu, etc. One of these interfaces is implemented on all natively-defined CATIA features, i.e., features defined in applications provided by Dassault Systemes. It must be implemented on any feature having a geometry that can be visualized in order to be taken into account during the visualization process. 
• The edition of the feature: This behavior is managed by the CATIEdit interface. This interface must be implemented on any feature for which one wants to display a specific panel allowing the edition of the feature's attribute values.
• The update of the feature: This behavior is managed by the CATIBuild interface. This interface must be implemented on any feature that is meant to be integrated in the update process. This interface allows the re-calculation of a feature's result based on the results of other features. 
• The Cut/Copy/Paste and Delete operations enabled on the feature: This behavior is managed by the CATICutAndPastable and LifeCycleObject interfaces. These interfaces are implemented on all selectable CATIA features and their re-implementation is dependent on any specific actions that must be performed during a CCP operation on the client-defined feature. They, therefore, do not need to be systematically re-implemented. However, in order to enable CCP operations, the CATICSOFilter interface (or its equivalent, depending on the application) must be implemented on the client-defined feature. This implementation is only possible if the application's UIActive object has delegated the authorization to the document's features. 

See also the technical article entitled "Integrating New Features in CATIA" [1] for a view of the different interfaces needed to be implemented in order for new client-defined features to be correctly integrated in CATIA. 

[Top]

Working with Features Defined "From Scratch"

A feature that is created "from scratch" is completely client-defined: it does not inherit any behaviors or attributes from any other existing feature. 

Here is an explanation of what enables each behavior described in the previous section to be taken into account for a feature created "from scratch":

The display of the feature in the specification tree: The application code managing the feature must have implemented the CATINavigateObject interface on the feature in order to display the feature's name and its children in the navigation tree. If the application code is present, the feature will appear in the navigation tree; if not, the feature will not be seen at all. The catalog containing the feature's StartUp may also be necessary for this behavior to be correctly implemented because the feature's StartUp may point to other features that would be part of the navigation process, whereas this information may not be present on the feature instance itself.

The visualization of the feature's geometry. The application code managing the feature must have implemented the CATI3DGeoVisu (or equivalent) interface on the feature in order to take the feature into account during the visualization process. If the application code is present, the feature will, therefore, be correctly visualized; otherwise, it will not be visualized at all. The catalog containing the feature's StartUp may also be necessary for this behavior to be correctly implemented because the feature's StartUp may contain attribute values that are not necessarily present on the feature instance itself.

The edition of the feature. The application code managing the feature must have implemented the CATIEdit interface on the feature in order to display a specific panel allowing the feature's attribute values to be modified. If the application code is present, the feature is selectable and this panel will be displayed; otherwise, the feature will not even be selectable and no panel will be displayed. If the catalog containing the feature's StartUp is not available, the panel may be incomplete: indeed, some of the feature's attributes can only be found on the StartUp.

The update of the feature. The application code managing the feature must have implemented the CATIBuild interface on the feature in order to allow its re-calculation in the event any dependent results have been modified. If the application code is present, the feature will be correctly re-built, otherwise, it will not be taken into consideration during the update process. The catalog containing the feature's StartUp may also be necessary for this behavior to be correctly implemented because the feature's StartUp may contain attribute values that are necessary to the build process but that are not necessarily present on the feature instance itself.

The Cut/Copy/Paste and Delete operations enabled on the feature. If the application code managing the feature is present, then the feature is already selectable both by its geometry and its entry in the specification tree. If the CATICSOFilter interface has been implemented on the feature, then it can be included in CCP and Delete operations. The catalog containing the feature's StartUp is not necessary for this behavior to be correctly implemented.

[Top]

Working with Derived Features

A "derived feature" has been created by the derivation of another existing feature. It has inherited the behaviors and attributes of the deriving feature. In this article, the "deriving feature" is considered to be a feature provided by one of the native CATIA applications. The receiving client or sub-contractor installation is assumed to contain the deriving feature's native CATIA application and catalog. 

 Here is an explanation of what enables each behavior considered in this document to be taken into account for a "derived feature".

The display of the feature in the specification tree: The application code managing the feature may have implemented the CATINavigateObject interface on the feature in order to display the feature's name and its children in the navigation tree. If it did not or if the application code is not present, the feature may still appear in the navigation tree, but its particular name may not be correct and its list of children may not be complete. The catalog containing the feature's StartUp may also be necessary for this behavior to be correctly implemented because the feature's StartUp may point to other features that would be part of the navigation procedure, whereas this information may not be present on the feature instance itself.

The visualization of the feature's geometry. The application code managing the feature may have implemented the CATI3DGeoVisu (or equivalent) interface on the feature in order to take the feature into account during the visualization process. If it did not or if the application code is not present, the feature may still be visualized, but the visualization may not be complete. The catalog containing the feature's StartUp may also be necessary for this behavior to be correctly implemented because the feature StartUp may contain attribute values that are not necessarily present on the feature instance itself.

The edition of the feature. The application code managing the feature may have implemented the CATIEdit interface on the feature in order to display a specific panel allowing the feature's attribute values can be modified. If it did not or if the application code is not present, this panel will not be displayed. If the application code is present but the catalog containing the feature's StartUp is not available, the panel may still not be displayed.

The update of the feature. The application code managing the feature may have implemented the CATIBuild interface on the feature in order to allow its re-calculation in the event any dependent results have been modified. If it did not or if the application code is not present, the feature will not re-built. The catalog containing the feature's StartUp may also be necessary for this behavior to be correctly implemented because the feature's StartUp may contain attribute values that are necessary to the build process but that are not necessarily present on the feature instance itself.

The Cut/Copy/Paste and Delete operations enabled on the feature. Even if the application code managing the feature is not present, it is possible that the feature can still be selectable. However, it is necessary for the CATICSOFilter and CATICcpAble interfaces to have been implemented on the feature itself in order to allow CCP and Delete operations. The application must, therefore, be present in order for this behavior to be enabled.

[Top]

Summary

The tables below summarize the different behaviors available for features created "from scratch" and for those that have been "derived" as accessed by the receiver of the document. Only the two following possibilities are taken into account in the receiver's configuration:

1. Both application and catalog are available 
2. Neither application nor catalog are available

The two other possibilities, 

1. Only the application is available, the catalog is not
2. Only the catalog is available, the application is not

are not considered because, in the first case,  the result of this configuration is too dependent on the specific application itself, and in the second case, the existence of a catalog without the application does not contribute to any different result as compared to the case where there is neither application nor catalog. 

[Top]

Table 2: Summary of CATIA behaviors on derived features

Feature Behaviors	Derived Feature Application and Catalog	Derived Feature No Application, No Catalog
Display in specification tree	Yes	Partial
Visualization of geometry	Yes	Partial
Feature edition	Yes	No
Feature update	Yes	No
Cut/Copy/Paste and Delete	Yes, if enabled	No

[Top]

References

History

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