Understanding StartUp Catalog

Technical Article

Abstract

Applications create feature objects by instantiating feature startups stored in catalogs. This article explains the properties of these catalogs.

What is a Catalog?

It is assumed that you are already familiar with the concepts of the Feature Modeler [1].

A catalog is a file containing StartUps so that an application can load and instantiate it into features. The features get stored in a persistent structure called container. Catalogs are very similar to shared libraries except that they contain data models instead of executable code.

How is a Catalog Defined?

Just like shared libraries that are compiled from C++ or other languages, catalogs get created from OSM [2] files. OSM is the language that is used to describe the contents of catalogs. Catalogs are produced at build-time with the help of a tool named CATfctEditorAssistant [3].

It is always possible to obtain the OSM equivalent of a catalog, if you have sufficient rights.

Catalog Location

For a catalog to be accessible by applications, it must be placed in the run-time view, in the OS_directory/resources/graphic directory (as defined by the CATGraphicPath environment variable). It is he mkCreateRuntimeView command that sets up the run-time view by copying files from several directories of your workspace. Catalogs are copied from the CNext/resources/graphic directory: this is where your catalogs should be saved.

This is why catalogs are never specified using their path but only with their name.

Since all catalogs share the same run-time view directory, their names must be chosen to avoid any conflict.

Catalog Client ID

A catalog is protected by a key called Client ID. When a catalog is created, a string must be supplied to be used as the Client ID of the catalog. From then on, access to the catalog will only be allowed it this client ID is correctly provided by the application code or to the CATfctEditorAssistant [3] tool.

Note that the client ID cannot be changed once the catalog is created.

Catalog Update Pattern

A catalog is never converted directly from an OSM file. The contents of the OSM file are first analyzed and then only the changes are added to the catalog. The reason of this pattern is to prevent changes that break already created features. Incompatible changes include StartUp and attribute removal for example.

Catalogs are thus created only once, empty and then upgraded by incorporating changes from the successive versions of the OSM.

Catalog Types

There are two types of catalog: the ones that are delivered by Dassault Systèmes and the ones that are created by CAA customers. Each kind of catalog has a different file extension: .feat for Dassault Systèmes' and .CATfct for the others.

Both types of catalog have the same purpose, i.e. containing StartUps that can be instantiated or derived from. The differences lie in the way the catalogs get accessed:

In Short

In this article, we have introduced the catalog, the document where the StartUps are stored.

References

[1] Feature Modeler Concepts
[2] Modeling Feature StartUps
[3] Managing Feature StartUp Catalogs

History

Version: 1 [Aug 2007] Document created