Action Indicator |
|
Action indicators can only be entered in the rule columns of a decision table. An action determines if the (complete) action entered in the main column is to be executed.
|
|
![]() |
As blank fields in the rule column are not permitted the action indicator 'no' (do not execute an action) must be entered in this case. |
Application Forms |
|
Application forms can be created
with the DataView standard tools, if you own the corresponding development
license.
If a field has been assigned to the application form and if a database access has been defined for the corresponding variable, the database access is executed if the variable is not yet initialized. In order to prevent this (e.g. if you want to request user input for this variable to be later written to the database), you need to enter "no_select" as pre-userexit in the corresponding field of the mask field allocation of the user form. |
|
![]() |
DataView Documentation |
Command |
|
Commands are instructions that - other than functions - do not return any results. Commands can therefore not be integrated into numerical expressions. Example: put ("The calculated value is:",VALUE) |
|
![]() |
This command must not be called with a conditional instruction. |
Condition Indicator |
|
Condition indicators can only be entered in the rule columns (R01, R02, etc.) of a decision table.
|
|
![]() |
As blank fields are not allowed in the rule columns in this case a condition indicator ':' (do not check condition) must be entered. |
Debug Lines |
|
A debug line ("D" entry in Comment row) is executed in debug mode only. Otherwise it is treated as a comment, i.e. ignored. This flag is only valid for action lines, not for condition lines (if, while, endif, etc.).
|
|
Decision Table |
|
Decision tables (DT) are tables containing decision procedures that define the conditions (or combinations of conditions) to be met, to trigger the defined action (or combination of actions). Example: IF (CONDITION_1 and CONDITION_2 and ...) are met THEN (ACTION_1 and ACTION_2 and ...). Decision tables are used to differentiate between several possible cases in logic applications.
|
|
Descriptor Function |
|
The descriptor function displays field descriptors of any field, field types, and name of the current mask in the "Field Information" form mask. This function is most important when defining LogiView variable database access (1:1 relation between table fields and field descriptor). The descriptor function is called by positioning the cursor in the corresponding field (in Edit or Search mode) while pressing Ctrl-D. .
|
|
Explanation Fields |
|
Explanation fields are part of the Syntax Assistant tool and can be used to create a decision table / procedure. Explanation fields are easily identified by braces ({}). During execution, a decision table / procedure must not contain any explanation fields. Example: {DAT_VAR|STR_VAR} = date({STR_EXPR}| ) means that the return value is either a date or string variable while the input parameters are either a string expression or a NULL value. |
|
![]() |
|
![]() |
How to Add Functions and Commands Using the Syntax Assistant 2 |
Logical Expression |
|
A logical expression may comprise:
|
|
![]() |
Comparison |
Logic Model |
|
A logic model contains decision
tables / procedures for a certain topic such as:
|
|
Multi-hit Table (Multi-hit Technique) |
|
Generally speaking, decision tables are interpreted row by row, i.e. the corresponding actions are executed and all following condition rows are ignored if all conditions of a rule are met. In multi-match tables, all condition rows are evaluated and corresponding actions are executed.
|
|
Procedure |
|
In a procedure there are neither alternative rules nor a strict division between conditions and actions. Procedures are used to describe action sequences. In addition to functions and commands that are available in decision tables, procedures may feature additional control structures such as 'if/elseif/else/endif' and 'while/done'. LogiView procedures may contain parameters. Parameters must be separated by commas and are interpreted as LGV input/output parameters by LogiView procedures. Date parameters must be entered in database format. If a string parameter is to transfer the comma symbol, the comma must be enclosed in high colons (').
|
|
LogiView Procedure Names |
|
The name of a LogiView procedure must be unique in combination with the logic models name.
The following is a list of userexits that are implemented in the default Java Client package, com.agile.jacc.callables:
In addition to these, userexits can also be registered by plugins using the API AxalantRepository.registerUsx. Currently, the AutoVue Java Client plugin makes use of this and registers the following userexits:
|
|
Recursion |
|
The action of a decision table calling itself is called recursion. Recursions are an efficient method of programming loops. |
|
Single-hit Table (Single Hit Technique) |
|
Opposite of Multi-hit Table | |
Userexit |
|
Userexits are C programs that cover several (standard) functions. E.g. the "cch_chk_men" userexit checks if the current field entry is identical to the corresponding entry of the selection menu. |
|
![]() |
DataView Documentation |
Variables |
|
LogiView is based upon a hierarchical system dividing logic models and decision tables/procedures. Thus the use of variables is defined and a modular structure is easier to maintain. While initialized constants are immediately available for all decision tables or procedures, variables must first be added to the general declaration list (menu: ) before they can be assigned to one of the hierarchical layers mentioned above.A variable is not defined as "valid" until it has been assigned:
|
|
![]() |
String variables which have the format "CC-CC" (two characters - dash - two characters) are considered as a date. |