Exchange of Creo Elements/Direct Modeling Attributes with Model Manager Database - Defining Personalities

Defining Database Attribute Personalities

This section discusses how to create custom commands which support the modification of Creo Elements/Direct Modeling attributes exchanged with the ModelManager database. Such commands may add minor refinements to the auto-generated commands created using sd-define-db-attribute or may be completely new commands.

In this section:

• Overview
• Basic Customization Of An Existing Command
• Pre-Set Personalities
• Creating New Custom Commands

Overview

Although a corporate database may impose certain restrictions on the data values (or combinations of data values) which are legal (via schema definitions and business rules), a division, department or group may wish to further refine these restrictions. Database attribute personalities are provided to fulfil this need.

The Creo Elements/Direct Modeling Integration Kit function sd-define-db-personality allows the creation of new commands which can be used to modify user-defined attributes exchanged with the ModelManager database.

Such commands are registered in Creo Elements/Direct Modeling's set of available commands which allows them to be accessed from menus, toolbars, etc. They can also be invoked from the Database Attribute Browser.

Typically definitions will be placed in the corporate customization files (that are sourced when ModelManager is started) and picked up by users throughout an organization. Personalities will generally be defined in site customization files. This will allow different divisions, departments and groups to provide different commands to their engineers

Basic Customization Of An Existing Command

The following example illustrates how a simple customization of an existing personality command (for a Material attribute) can be created:

(sd-define-db-attribute "Material" 
                        :class-name "MODEL_3D"
                        :attachment :contents
                        :keys '(("MODEL_MAT_ID" :label "Id" :option :id)
                                ("HEAT_TREAT" :label "Heat Treat")
                                ("FINISH" :label "Finish"))
                        :allowed-owner-types '(:part :assembly)
                        :master :db
                        :on-copy :copy
                        :on-split :detach
                        :command-name 'assign_material_attribute)

(sd-define-db-personality "Material"
                          :attribute-names "Material"
                          :auto-command t
                          :category "/Manufacturing"
                          :icon "bitmaps/personalities/material.bmp"
                          :allowed-values '(:FINISH (:polished :rough)))

The main intent of this customization is to further restrict the set of allowed values for the Finish database attribute. This definition further restricts any schema conditions to allow only the values "POLISHED" and "ROUGH" to be permitted by the revised assign_material_attribute command. Other than this, the new command will be identical to that auto-generated by the original attribute definition.

The supplied set of allowed values must be a subset of the values permitted by the database schema. Although the above example illustrates how one database attribute may be restricted, restrictions for many database attributes (compatible with the attributes definition) may be specified in the property list.

Notice that the value of the :auto-command key is t. This specifies that the personality is to be auto-generated from an existing attribute definition (as specified by the :attribute-names key). If :auto-command is nil, a completely new custom command will be generated (see below). In the above example, no :command-name parameter is specified and so the existing command for the associated attribute is overridden. However, if a :command-name were specified, a new command would be created and the existing (default) command would still be available.

The parameters :category and :icon control how the personality is represented in the Database Attribute Browser. The :category must be a string path (beginning with '/') controlling where in the browser tree structure the personality should appear. Any :icon file (Windows bitmap or X pixmap) will be displayed in the browser node for the personality and will be associated with the Creo Elements/Direct Modeling available command entry.

Pre-Set Personalities

Sometimes it is useful to be able to quickly create pre-set attribute values which represent common characteristics. For instance, consider for the Material user-defined attribute example. If a particular department frequently used two steels S7 and S8, the following personality definitions would support the creation of such pre-set materials:

(sd-define-db-personality "S7"
                          :attribute-names "Material"
                          :auto-command t
                          :command-name 'assign_s7
                          :category "/Manufacturing/Material"
                          :always-offer-defaults t
                          :default-values 
                            '(:MODEL_MAT_ID :Steel :HEAT_TREAT :H7 :FINISH :polished))

(sd-define-db-personality "S8"
                          :attribute-names "Material"
                          :auto-command t
                          :command-name 'assign_s8
                          :category "/Manufacturing/Material"
                          :always-offer-defaults t
                          :default-values 
                            '(:MODEL_MAT_ID :Steel :HEAT_TREAT :H7 :FINISH :rough))

Notice the use of the :default-values parameter to specify the pre-set values for each of the database attributes contained in the Material attribute. These defaults override any defaults provided by the database schema. The syntax for specifying :default-values is similar to that for :allowed-values (although only a single value is provided for each key).

In the above examples, the :always-offer-defaults parameter is t. The effect of this is that when the owner object is selected for such a personality command, the supplied default values are always presented (even if the object already has values for the values for the database attributes is question). Thus, the effect of such personalities is to always impose their preset values. If this behaviour is not preferred, then :always-offer-defaults set to nil can be used to ensure that the default values are only presented when an object contains no value for the object in question.

Creating New Custom Commands

Previous examples have shown how the auto-generated commands (created when a database-exchange user defined attribute is defined) can be 'tweaked' to provide different behaviours. However, it is also possible to create completely new custom commands for modifying such attributes. Whilst these commands can provide whatever functionality is required, there are certain rules and conventions which should be followed if these personalities are to be compatible with the rest of the system.

To create a new custom personality, the :auto-command parameter must be nil and the new command must be specified using the :command-name parameter. Although, not essential, it is advisable that the :attribute-names provides a list of all database-exchanged user-defined attributes modified by the new command. This is because the Database Attribute Browser uses this list to determine whether a personality definition is applicable to an object. Note that the :allowed-values, :default-values and :always-offer-defaults options are not applicable to non auto-generated commands.

The Creo Elements/Direct Modeling Integration Kit functions for database-exchanged user-defined attributes are useful when writing custom personality commands. The following rules and guidelines should be followed when defining a custom personality command:

• the command must always contain an option named OWNER
• following selection of the owner, the options of the command will generally be populated by inquiring the current attribute values using sd-inq-db-attribute-values.
• the command should provide as much validation of input values as possible on data entry and before the command completes
• before the command completes, sd-assign-db-attribute should be used to set the key values corresponding to all database attributes modified by the command
• the Integration Kit function sd-db-attribute-browser-set-active-object. can be used to set the active object in the Database Attribute Browser.

To assist in developing custom personalities, the function sd-set-db-attribute-verbose-error-handling can be used to cause errors detected by the Integration Kit functions to be reported at the user interface.