|
The
api_save_entity_list function accepts the following arguments:
|
|
|
An open output stream pointer (FILE*)
|
|
|
A logical indicating the file mode of text or binary
|
|
|
An
ENTITY_LIST pointer
|
|
|
The function saves the entity to the output stream.
|
|
|
Top level entities (e.g., body entities) are always the first records in the save file. Thereafter, the data records are in no particular order. A call to
api_save_entity_list with a list of
n top level entities always places these entities in the first
n records of the save file.
|
|
|
api_save_entity_list_file and
api_restore_entity_list_file also control reading and writing of data during a save or restore. Each of these procedures take two arguments: a
FileInterface pointer and an
ENTITY_LIST pointer.
|
|
|
FileInterface is an abstract base class. By deriving classes from
FileInterface,
ACIS models can be saved and restored to media other than a stream file. For example, it is possible to derive
FileInterface classes that allow models to be saved and restored to a block of memory or by using a pipe to transfer data between two processes.
|
|
|
There are classes derived from
FileInterface for saving and restoring in binary or text format to stream files. These are defined in the
sabfile.hxx and
satfile.hxx files.
|
|
|
If a new type of
FileInterface class is being derived, derive it from
BinaryFile, which is defined in the
binfile.hxx file. The
BinaryFile class provides most of the virtual methods of the
FileInterface class and only the four virtual methods that are specific to the derived class need to be implemented.
|
|
|
Applications are responsible for opening and closing the file, and for making sure that the file pointers are positioned correctly when the save or restore function is called. Each function expects that the file is open and positioned at the byte where the save or restore is to begin. When the function finishes, the file is positioned after the last byte of the body or entity saved or restored.
|
|
|
The process of copying an
ENTITY_LIST is analogous to performing a save and restore. The copy algorithm is described with the save and restore algorithms.
|
|
|
Problems can occur in several areas if you use two different C runtime DLLs (e.g., one release and one debug) when using ACIS. Using the release DLL with an application debug configuration is a common source of access violations for save and restore. Refer to the "C Runtime Library DLL" topic in the
Application Development Manual for more details.
|
|
|
Integer identifiers, unique to a given history stream, can be requested for each entity. These IDs remain constant through roll, save and restore. An entity can be returned from a given ID when the entity is alive in the active state of the history stream.
NULL is returned when the entity is not alive. This requires two SAT files changes: an extra integer in each entity and the number of tags assigned in the history stream.
|
|
|
The format of
ENTITY and
HISTORY_STREAM records accommodates the addition of entity IDs. An integer field in the entity record holds the entity's ID. A value of -1 indicates that an ID has not yet been requested for the
ENTITY. This is field #2 in any entity record, where the entity type is field #0. An integer field in history stream records (part of the history data section) holds the next available entity ID in that stream. This is field #3 in the history stream record, where "history_stream" is the first field.
|