Using and configuring actions

Besides managing development resources, source code and documentation, the ClassEditor provides an interface for activating external actions as calling a compiler or linker process. External processes or other actions can be configured using the action browser by selecting Objects/Actions from the main menu in the ClassEditor . In order to call the action browser outside the ClassEditor , one may also start the ActionBrowser tool (see Action Browser)

Each action may consist of a number of steps or may call a process directly. In order to define a complex process that includes a number of steps to be executed, Actions are reusable, i.e an action defined once might be called as step in another action. There are different types of actions, which might be defined:

• Composed action (any action type, usually OACT_undefined )
• Command actions for calling external procedures ( OACT_command )
• Program action for calling an external program ( OACT_program )
• OSI action for calling an OSI function ( OACT_expression )
• Function action for calling a function in the database context class ( OACT_function )

• When calling actions in a class or project context, several option variables are set by the ClassEditor, which might be referred in action calls. In order to set options for action call in another application context, one may call the SetupOptionsForObject() context action, which is implemented for following development resources:

• ODC_ImpClass
• CLS_NAME - Class name
• CLS_IDKEY - Class name and namespace number (e.g. String|50 )
• DEBUG - depends on the debug option switch ( YES for on and NO for off)
• PROG_LANG - Name of the selected programming language minus PL_ prefix (e.g. CPP when PL_CPP has been selected)
• SRC_EXTENSION - typical source file extension for the selected programming language (e.g. cpp )
• IF_CLASS - Class provides an OSI interface ( YES ) or not ( NO )
• SUB_SYSTEM - Required for Microsoft compiler ( Windows )
• STORE_OBJ - Object files are to be stored separately and not in a library ( NO )
• ODC_Executable - same options variables as for ODC_ImpClass plus:
• STORE_OBJ - YES when executable has at least one function and NO otherwise
• SUB_SYSTEM - Console when executable type is EXT_ConsoleProgram and Windows otherwise
• BIN_NAME - Name of executable (same as CLS_NAME ) or module name, when executable type is, EXT_Library , EXT_CTXInterface or EXT_DotNetInterface
• BIN_EXTENSION - exe or dll when executable type is, EXT_Library , EXT_CTXInterface or EXT_DotNetInterface
• ODC_Module - same options variables as for ODC_ImpClass plus:
• MOD_NAME - Module name (same as CLASS_NAME )
• ODC_Project
• PRJ_NAME - Project name
• PRJ_ROOT - Project path defined as root path in the project definition
• PRJ_RELPATH - Path for current project relative to the project root path
• PRJ_PATH - Complete project path ( %PRJ_ROOT%/%PRJ_RELPATH% )
• PRJ_SOURCE - Sub directory for source files of the project ( SOURCE field in project definition)
• PRJ_INCLUDE - Sub directory for header files of the project ( INCLUDE field in project definition)
• PRJ_LIB - Sub directory for library or object files of the project ( LIB field in project definition)
• PRJ_EXE - Sub directory for executable files of the project ( EXE field in project definition)
• PRJ_BAT - Sub directory for project command files ( BAT field in project definition)
• PRJ_SCRIPT - Sub directory for OSI source files of the project ( SCRIPT field in project definition)
• PRJ_TEMP - Sub directory for temporary files as error logs ( TEMP field in project definition)
• PRJ_HIER - Path to the project through the project hierarchy.
• ENV_NAME - Environment name for the selected project environment (e.g. vs , gcc or obe )
• SDB_ValueList (Enumerations)

• CLS_NAME - Enumeration name

• CLS_IDKEY - Enumeration name and namespace number (e.g. AccessModes|50 )

In order to define a composed action, a number of sub actions has to be created or inserted to the action definition. Actions referred to as sub actions might be composed actions, again. No specific action type is required. One might define action properties as start or stop message, but those will be ignored completely.

Composed action do not refer to procedure or response files.

A command action calls a procedure (command file) defined on the procedure tab and stored externally. In order to define a proper command action, action properties have to be filled:

Name - Action name

Object path - Access path to the object to be processed. Option variables are set according to the selected object type.

Action type - OACT_command

Start message - Message to be displayed in the application output area when starting the procedure call. The message may contain option references enclosed in %...%. Available options depend on the context, in which the action is called.

Action call - is the name of the procedure to be called. The procedure name might be a generic one referring to one or more options as in the example above. Supported procedure names (e.g. gcccompile_cpp for environment gcc and programming source extension cpp ) have to be defined in the procedure list for the action.

Procedures might be defined here within the database, but have to be exported to an external folder. The procedure location depends on he symbolic path defined o the Path property.. In order to generate the procedure temporarily to an external location for being executed, the Temporary option has to be activated. This allows replacing option references within the procedure instead of passing them as parameters. When initializing the development database, default procedures are copied and stored to required location. When adapting procedures to specific requirements, this might be done here and updated procedures might be stored by clicking the Export button. The full file name for the procedure's location is displayed in the Full path field.

Parameters - In order to support parameters for different targets, each parameter to be passed to the procedure has to be defined on a separate line. Parameters may refer to option values, which are usually provided in the application context.

Stop message - Message to be displayed in the application output area when the procedure terminates. The message may contain option references enclosed in %...%. Available options depend on the context, in which the action was called. The RESULT_FILE option refers to the location for the last file generated.

ODABA Script Interface (OSI) function are, typically, called in order to generate external resources. Since compiler are not able to read code from an ODABA database, header and source code files are generated to external locations. The simplest way for achieving this is by calling OSI templates or functions, which are stored in the resource database ode.dev . The following fields should be filled in order to call an OSI function:

Name - Action name

Object path - Access path to the object to be processed. The called OSI function has to implemented in the object type the access path refers to. Option variables are set according to the selected object type.

Action type - OACT_expression

Collection - should be anabled, when the action processed the complete collection rather than a single instance in the collection.

Start message - Message to be displayed in the application output area when starting the procedure call. The message may contain option references enclosed in %...%. Available options depend on the context, in which the action is called.

Action call - is the name of the OSI function to be called. The OSI function has to be implemented in the ode.dev resource database.

Parameters - In order to support parameters for different targets, each parameter to be passed to the procedure has to be defined on a separate line. Parameters may refer to option values, which are usually provided in the referenced object context.

Stop message - Message to be displayed in the application output area when the procedure terminates. The message may contain option references enclosed in %...%. Available options depend on the context, in which the action was called. The RESULT_FILE option refers to the location for the last file generated.

Context functions have to be provided as business rules in the database context library. For the ClassEditor, this is an integrated part of the database library ( opa.dll ) and cannot be cutomized, i.e. only functions provided by the system might be called.

Name - Action name

Object path - Access path to the object to be processed. The called context function has to implemented in the object class the access path refers to. Option variables are set according to the selected object type.

Action type - OACT_function

Start message - Message to be displayed in the application output area when starting the procedure call. The message may contain option references enclosed in %...%. Available options depend on the context, in which the action is called.

Action call - is the name of the context function to be called.

Parameters - In order to support parameters for different targets, each parameter to be passed to the procedure has to be defined on a separate line. Parameters may refer to option values, which are usually provided in the referenced object context.

Stop message - Message to be displayed in the application output area when the procedure terminates. The message may contain option references enclosed in %...%. Available options depend on the context, in which the action was called.