MSC.SuperModel provides additional customization capabilities in File Manager. Users may now develop PCL functions that are called by the File Manger during certain file operations. The customized actions can be defined to occur before or after the File Manager has completed its specified task. In addition, customized error handling functions may be added that are invoked if File Manager has difficulty performing its intended operation. This allows users to perform any necessary clean up operations if the failure affects their customized tasks.

File Manager has been extended to allow user defined functions to be a regular part of performed file operations. Similar to the "user_db_open" and "user_db_close" functions of MSC.Patran. That can be used to perform tasks such as enabling and disabling custom PCL menus, MSC.SuperModel now provides a method for operations in addition to the normal File Manager tasks. MSC.SuperModel does not limit the number of users that can customize a feature; it provides opportunities for custom operations before or after File Manager completes its task and allows for custom error handling.

The following File Manager functions now support user customization:

File Manager can be instructed to invoke a user-supplied function either:

Together, this collection of functions allows users the ability to interact with File Manager operations robustly and cleanly.

MSC.SuperModel allows multiple users to register their own function names with a particular File Manager operation. During the registration, the operation sequence of the functions are specified as ”PRE”, ”POST”, or ”ERROR”.

There is no limit to the number of functions that can be registered. The File Manager calls all registered functions at the appropriate operation sequence.

User functions that operate prior to File Manager’s own operation (i.e., those registered as ”PRE” tasks) are allowed to terminate the file operation. This is accomplished by returning a non-zero value in the status argument of any custom function. When File Manager receives a non-zero status, all subsequent operations are terminated, including additional custom functions that are yet to be invoked, File Manager standard process functions, and any registered ”POST” or ”ERROR” functions. An error message is posted for the user and all file states remain as is prior to the operation.

There is no limit to the number of functions that can be registered. The File Manager calls all registered functions at the appropriate operation sequence.

The following PCL is required to register custom functions with the File Manager:

smdl_fm_customize.register(<my_function>, <FM_OPERATION>, <FM_SEQUENCE>)

where,

Both stand-alone and class-method functions are supported. The user is responsible for ensuring the argument compatibility of the registered functions with the data to be passed by File Manager (see "Shared Information from File Manager" section).

For example, the following lines tell the File Manager to execute two custom functions. The first is called after the File Manager has finished an Open file operation and is a stand-alone or globally defined function. The second is called if File Manager encounters an error while performing a Close file operation.

smdl_fm_customize.register("my_open_post", "OPEN", "POST")

smdl_fm_customize.register("my_custom_class.close_error", "CLOSE", "ERROR")

These calls should be placed in the p3smdl_epilog.pcl file that is automatically loaded by MSC.SuperModel during initialization. This file is similar to the MSC.Patran p3epilog.pcl file because it is assumed to reside in:

To allow custom functions to properly operate with the File Manager, a predefined set of arguments is passed to any registered function. This intentionally limits the user’s knowledge of the file system to maintain data security and integrity.

In addition, each function is expected to return status as an integer value. This status is always the last argument present. “PRE” functions may use the status to terminate the file operation (see Custom Functions Return Status and Process Termination sections).

The information passed to any given function depends on the associated standard File Manager operation, as shown in the table below.

where

ID = Unique integer that the system uses to identify a file

Description = String that identifies a file

Hierarchy = String array of branch names where the file resides

Type = String label that designates the file's type.

Access = String that denotes the ability of the user to modify the contents of a file

# - Designates the order of the arguments passed (1,2,3,4,5)

* - Argument is valid for PRE, POST & ERROR calls

+ - Argument is valid for POST calls only

[blank] - Argument NOT passed

@ - SAVE AS receives two file IDs; for the original and copy (the copy is only valid for the “POST” task)

A custom function for handling SAVE_AS operations would have the form:

my_custom.save_as(orig_file_id, save_file_id, save_desc, save_hier)