Functioning (inquiry)

Description

This template is called from a function, a button at the bottom of the screen, a menu or a contextual menu. This template is used to view a group of records in a table, selected as a function of the criteria entered by the user or even passed by the programme. This template offers the possibility to display the results of the inquiry in the form of a graph.

Ergonomy

The inquiry is presented with a header screen, containing the principal criteria for the record selection and a principal tab constructed from a group of records to be displayed. This tab is a grid in which each line corresponds to a record. There is then the possibility to have various additional tabs. Warning! this template does not automatically load the information in these tabs; the loading of the tabs must be programmed in the LECTURE action. When the criteria are numerous, they can be grouped in a particular screen, which will display when the the user clicks on the CRITERIA button. The GRAPH button, is used to display a graph, on the condition of supplying the data to be displayed in the GRAPH action.

Standardisation of the elements in the dictionary

    Header screen : must be named "CONS" + inquiry code + "1"

    Detail screen : must be named "CONS" + inquiry code + "2"

    The 2 screens are grouped in a principal window named "FCNS" + inquiry code. This window is of the type "full screen".

    Criteria screen : must be named "CRIT" + inquiry code. It is optional.

    This screen is encapsulated in a criteria window named "DCNS" + inquiry code. This window is of the type "dialogue box". It is optional.

    Inquiry : it is identified by the inquiry code on 3 characters. Warning! for the custom/specific, this code must start with one of the following 3 characters : X, Y or Z. The inquiry groups the principal window with the criteria window.

   Action : must be named "CONS" + inquiry code. In this action, it is mandatory to specify the inquiry code. Following this it is possible to define the parameters.

   Function : must be named "CONS" + inquiry code. In this function, it is mandatory to specify the action and any of the values for the parameters in this action.

The screens

for the detail screen in the principal window, the bottom of grid variable must be named NBLIG.

for the criteria screen, if the template is required to save the parameters of this screen, it is necessary that the field MEMO is present. In addition, if the detail screen for the principal window can be parameterized, it is necessary that the field ECRAN is present. The principle is as follows: at the base of the detail screen declared in the principal window, the user can construct a group of detail windows by the Parameterization/General Parameters/Inquiry screens function. These screens can only display certain columns and these are in an order that can be different with respect to the base screen. The user chooses one of these screens, for the ECRAN screen of the criteria window.

      

The processes

The template is a supervisor process that calls two annex processes : the standard process and the specific/custom process, if they are entered in the dictionary for the action. These two processes are structured in the same way, that is to say they start with a label ACTION, which process the different events likely to arrive during the execution of the function.

Standard process
It is named CNSxxxSTD ( xxx is the code for the inquiry). 
This process, supplied by ADONIX, must absolutely not be modified in customization. 

The specific/custom process
It must be names CNSxxxSPE ( xxx is the code for the inquiry). This process is not supplied by Adonix, but is can be developed in customization (both for the standard functions for which additions are required and for custom/specific functions).

The Actions

The standard or specific process described by the label $ACTION to write in the following fashion( where XXXXXX is the event code ) : 

$ ACTION
Case ACTION
   When "XXXXXX" : Gosub XXXXXX
   When default
Endcase
Return

Each event is identified by an alphanumeric code contained in the ACTION variable. If there is no process for the event, the functioning of the function will not be impeded by it. It is in the sub-programme $ACTION, that it is pointed to the added label. Within the "ACTION case " syntax is used to specify that as many lines as events are to be completed. The $ACTION is called from the supervisor process by GOSUB ; this therefore makes it possible to use the local variables from the supervisor process. 

Attached to this is the list of actions. Next the detailed description of these actions is found. Described here is the calling context for the OBJective of these actions.

Add the specific/custom actions to the standard

By, default, for a single event, the specific/custom action is called before the standard action.

It can cancel and replace the standard action if it sets the variable GPEto the value 1. 

To execute the standard action with the specific/custom action, copy the standard process in the specific/custom action, then add the specific/custom process and finally set the variable GPE to the value 1. Example :

Supervisor process
GPE=0
Gosub  ACTION  From  trait_std              ( call to the standard )
If GPE=0
   Gosub  ACTION  From  trait_spé.            ( call to the specific/custom process )
Endif

Specific/custom process
$ ACTION
Case ACTION
   When "OUVRE" : Gosub OUVRE
   When default
Endcase
Return

$OUVRE
...                                                                ( specific/custom action OUVRE )
GPE = 1                                                     (no call to the standard following the specific/custom)
Return

---