Refer to documentation Implementation
Presentation
The header is used to identify the screen and provide the general characteristics.
Close
Fields
The following fields are present on this tab :
| The screen code can contain 1 to 10 alphanumerical characters. The first character must necessarily be a letter. It must not be an Adonix reserved word. |
| The screen abbreviation is comprised of 1 to 4 alphanumerical characters where it is mandatory that the first is a letter. It must not be an Adonix reserved word. |
|   |
| This check box is used to identify that a screen is never used as it is (neither in interactive or in import), but only serves as a template in the creation of other screens. These screes are never validated. |
Close
Presentation
Found here is the information linked to the global management of the screen.
These two items of information are used to identify if the screen described in the dictionary must actually be created in the folder database. It will be created if the following two conditions are realized simultaneously:
the activity code field is empty or that the activity code (defined in the corresponding table) is actually activated.
the module to which the screen is attached has been declared as active in the folder.
An activity code starting with X, Y, or Z identify the screen as being completely specific/custom, that is to say it will not be updated in the case of folder revalidation.
The screen is firstly defined by its type, which can be :
Header
Tab
Dialog box
Full screen
Full screen with list
Header and tab are particularly used in the management of objects and inquiries and in the "window entry" template.
Dialogue box is used in the window entry template.
Full screen is used in grid object and in a "window entry" template.
Full screen with left list is used in a simple object with a single screen and in a "window entry" template.
The first three types (header, tab, dialogue box) require the additional entry of a number of lines and columns remembering that the tab tiles takes 1 line, the section outline takes 1/2 line per line and that the maximum is :
in low resolution, 20 lines, 84 columns (64 columns, if there is a left list).
in high resolution, 28 lines, 112 columns (88 columns, if there is a left list).
These two fields (lines, columns) are considered as part of the setup. There is thus no need for the protection through an activity code for a modification made by the specific.
This tick box is used to identify that a screen is never used as it is (neither in interactive or in import), but only serves as a template in the creation of other screens. These screens can be used for instance for the entry transaction generations.
Found here is the name of the two processes used in liaison with the screen:
The standard process is the processing in which the "standard" actions (STD code) attached to the field in the screen are found. For an object XXX, the standard processing name is SUBXXX: this standard is strongly advised but remains optional. On the validation of the screen, this process is updated (or created if it did not previously exist), when a "standard" action is added to a field. In fact the sub-program label is generated with the transfer to setup of the field value ; it remains for the developer to write this sub-program.
The specific/custom process is the process in which the "specific/custom" actions (SPE or SPX code) attached to the field in the screen are found. For an object XXX, the specific processing name is SPEXXX: this standard is strongly advised but remains optional. On the validation of the screen, this process is updated (or created if it did not previously exist), when a "specific/custom" action is added to a field. In fact the sub-program label is generated with the transfer to setup of the field value ; it remains for the developer to write this sub-program. The update of this field does not require the protection by an activity code.
A section is a group of fields presented in a framework with an optional title. Each field of the screen must be positioned in a section. The order entry of the fields in each section is imposed (when the Tab key is used, the cursor moves from top to bottom and right to left).
The characteristics of each section are as follows :
the Tile appears in the upper part of the framework. This text can be translated. It can be evaluated.
the Type of section can be:
Section type | Definition |
List | list of fields independent one from another |
Grid | The fields are organized in a scrolling grid of lines (horizontally and vertically if necessary) |
Text | Display of text in a fixed background, without it being entered |
Hidden | Declaration of a hidden list section. Is used to include in a screen technical fields that are not displayed but usable by the processes linked to the screen. |
The position, line, column are used to position the sections with respect to the others. It is necessary to simulate a grill for the section design, then indicate for each, the positioning by the use of coordinates (line.column) of its upper left angle, the occupation by the number of lines and the number of columns in this fictional grill. For example:
Section | Position | Line/row | Column |
A | 1.1 | 2 | 2 |
B | 1.3 | 1 | 1 |
C | 2.3 | 1 | 1 |
D | 3.1 | 1 | 1 |
E | 3.2 | 1 | 2 |
F | 4.1 | 1 | 3 |
the rankis used to define the order in which the sections are entered: the sections are entered in ascending order of rank when moving from one field to another using the Tab key. In addition, it is used in programming to identify a section. For example, display all the fields of the section no. 10 corresponds to: Affzo 10
It is thus strongly recommended to avoid modifying the rank of the block in the screen definition.
Length is used to define the maximum length in number of characters that is reserved before the entry fields to place the field titles in a list section. This length is approximate: the character font is proportional so the length is only an average. In this way, it is possible that the titles which are slightly too large may be displayed. Generally, 20 is a good value.
Act is used to make a section of data optional; if an activity code is present, it can be active or inactive. If it is with a dimension, it is used to make the number of lines in a grid section parameterizable. An activity code starting with X, Y, or Z makes the section specific/custom, that is to say it cannot be updated during a folder revalidation.
Line,Optionsand Bottom of pageare only entered if the section is of the type Grid. In this case:
Line contains the maximum number of lines that can be entered in the grid.
Bottom of page contains the name of the technical variable storing the number of lines actually entered. It must be defined as being available for entry in the fields tab, with the data type ABS. If the grid section will be invisible, then this variable will be defined in invisible mode.
Options contains a list of characters, each representing a database function authorized in the grid (if it is present). These characters can be selected with the help of a window accessible by right button. The following functionalities are available:
Character | Grid management function |
K | Previous & next line in entry mode |
A | Cancellation of a line |
D | Cancellation of an interval of lines |
R | Addition of lines at the end of the grid |
I | Insertion of lines |
S | Cut |
B | Copy |
C | Paste |
T | Load all the records in the grid |
? | Recherche |
+ | Column justification |
= | Automatic record mode |
1-9 | Number of fixed columns (from the 1stst column) |
This field is from now on used for "web-services". It is to be entered for the tabs containing their own left list. For example: BPABPR screen.
This grid is used as an aid to the entry of the fields in the next tab: it repatriates the field characteristics for the listed tables.
Close
Fields
The following fields are present on this tab :
Characteristics
| If this field is not assigned, the screen will always be generated. If this field corresponds to an inactive activity code, the screen will not be generated. |
| Select a module for the setup. Use this field to specify if the screen has to be created in the folder database. This is the case when the module linked to the screen is active on the folder. |
| The screen is firstly defined by its type, which can be :
The first 3 type (header, tab, dialogue box) requires the additional entry of the number of lines and number of columns by remembering that the title of the tabs takes 1 line, the contour of the sections takes 1/2 a line by feature and that the maximum is 28 lines, 112 columns (88 columns, if there is a left list). These two fields (lines, columns) are considered as being parameterization : a modification carried out by the specific/custom therefore does not required protection by activity code. |
|   |
|   |
|   |
Scripts
| Process in which the "standard" actions will be looked for (code STD) attached to the screen field. For an object XXX, the standard process name is SUBXXX : this standard is strongly advised but is not however mandatory. On the validation of the screen, this process is updated (or created if it does not exist already), when a "standard" is added to a field. In fact, the label for the sub-program is generated with the transfer to the parameter with the value of the field ; It is up to the developer to write this sub-program. |
| Process in which the "vertical" actions will be looked for (code SPV) attached to the screen field. For an object XXX, the name of the custom/specific process is SPVXXX : this standard is strongly advised but is not however mandatory. On the validation of the screen, this process is updated (or created if it does not exist already), when a "vertical" is added to a field. In fact, the label for the sub-program is generated with the transfer to the parameter with the value of the field ; It is up to the developer to write this sub-program. The update of this field does not require protection by activity code. |
| Process in which the "specific/custom" actions will be looked for (code SPE) attached to the screen field. For an object XXX, the specific/custom process name is SPEXXX : this standard is strongly advised but is not however mandatory. On the validation of the screen, this process is updated (or created if it does not exist already), when a "specific/custom" is added to a field. In fact, the label for the sub-program is generated with the transfer to the parameter with the value of the field ; It is up to the developer to write this sub-program. The update of this field does not require protection by activity code. |
Grid Blocks
|   |
|   |
| This type of block defines the presentation of the fields for the interior of a block.
One parameter variable is required for blocks of the Browser and HTML editor types. For security reasons, the other block types that were used in version 6 in web server mode are no longer used. |
| the position, line, column that are used to space the sections with respect to the others. See the detail in the document linked to the function. |
|   |
|   |
| If necessary, these fields are used to indicate a number of columns and minimum number of lines for a grid section. |
|   |
| Specify the entry range. The blocks will be entered in the order of ascending ranges. Used to define the order of entry in the sections : in ascending order of the ranks when advancing by Tab from one field to another.. In addition, it is used in programming to identify a section. For example, to display all the fields in section 10, write : Affzo 10 |
| For a section of the type list, this field indicates the number of characters allocated to the title of each field. As a function of the space available, it can be 20,15 or 12 characters. |
| If the activity code is not assigned, the block will always be generated. |
| For a section of the grid type, this field type indicates the maximum number of lines in the grid. |
| For a section of the grid type, this field contains a list of characters, each representing an authorized basic function(if it is present) in the grid. These characters can be selected with the help of a selection window. The following functionalities are available:
|
|   |
|   |
| For a section of the grid type, this field defines the name of the variable at the bottom of the grid. It is a technical variable storing the number of lines actually entered. It must be defined as in entry mode, in the fields tab, with the data type ABS. If the grid section is to be hidden, this variable will be defined in invisible mode. |
| Representation of the "grid" section in the screen :
For the last 3 values, a screen for the "Graphical parameters" is accessible from the contextual menu. |
| This field is from now on used for "web-services". It is to be entered for the tabs containing their own left list. Example : BPABPR screen. The number of the associated grid section is indicated in the list section. |
| This field is used to select the portal view, for the Flash sections |
Grid Reference tables
|   |
| This grid provides a help on the entry of the fields in the next tab. The system recovers the characteristics of the fields in the listed tables. |
Close
Action icon
Available for a section of Browser type.
Available for a section of Office type.
Close
Presentation
This tab is used to define all the fields of the screen in a drop-down menu.
Defined in this column is the name of the screen. In order to benefit from the trans-class, it must, if possible, have the same name as the field in the table to which it makes reference. A field with the name FIELDNAME defined in the screen with the abbreviation ABV1, can be accesses by the syntax [M:ABV1]FIELDNAME.
For custom/specific fields, the field name must start with X_, Y_ or Z_.
Possibility to choose one of the three titles for the field stored in the table or an evaluated label or another text.
Is used to place the field in a section. By the position, the field location is identified. If several fields are placed on the same line, the line number is followed by a sequence number.
This field is used to align the fields, with respect to each other in the same section. It is again necessary to imagine a fictional grill. The background text and the associated entry field each count as a column. The number of columns occupied by the field is specified in this field. The fields of data type W are expressed in a number of columns and not in a number of characters. The supervisor considers that the last field of a line takes the number of columns necessary to align the line as a function of that which is the longest.
The data type for the field is defined in the first of these three columns. This type is defined in the types dictionary. Either it is the database defined in the data typesdocumentation, or it is a type linked to an object (BPC for a customer code, ITM for a product code) or it is a type using particular characteristics (NAM for long name, SHO for a short name…). Certain types require additional information given by the Menu and Length columns. The following types are concerned:
Indicate whether the field is entered, displayed, invisible or technical (not taken into account by the Web-services).
The activity code can carry a dimension. In this case, the corresponding field is sized according to the value associated with the activity code. Activity codes starting with X, Y, or Z correspond to the specific fields that are not affected by the folder updating.
This column defines the options applicable on the entry of the field. These options are realized by characters that can be concatenated when several options are required. It is possible to choose these options thanks to a selection window. A detailed description for all the possible options is available. The combination of these options allows the supervisor to apply a specific entry format for the field. However, it remains possible to directly enter the entry format using the contextual menu (for the format syntax see the format$ help).
The Mandatory field is used to define if the field can be empty or whether it must contain a value not equal to "empty". The following can be understood by "empty" field; empty length field, null numeric value, a local menu value equal to zero (no choice) carried out or an empty date [0/0/0].
These field are available once there is a data type linked to the object. It is necessary to specify whether a tunnel to the object in the field contextual menu is to be proposed. With the "link" field, it is possible to automatically display the short or long title linked to the code entered in this field.
It indicated the length of the field on the screen and therefore is used to truncate this field on the screen. The entry in the field will be scrolling. By default, alphanumeric fields whose length is greater than 30 are truncated by the supervisor.
Constant or variable used to initialize the field.
Possibility to restrict the access to this field reserved for customization. The update of this field does not require the protection by an activity code.
This field is defined as being available for entry, however in certain conditions, it is possible that this field should not be entered.
On a grid section field, the authorized objects are: the check box and the icon.
The key-word referencing a help text associated with the field is entered here. The update of this field does not require the protection by an activity code.
Possibility to add a specific style to a field by the setup. This is reserved for customization. The update of this field does not require the protection by an activity code.
Possibility to add a check on the field in the setup. The update of this field does not require the protection by an activity code.
This is used to identify the sub-programs that will be run before or after the entry of a field. Also makes it possible to identify the actions of the contextual menu for the field. This grid is to be defined if necessary, for each field.
This is used to assign values to the parameters in the actions. A single table of parameters is entered for all the actions of a field.
The fields are organized in a scrolling grid of lines (horizontally and vertically if necessary)
Fields
The following fields are present on this tab :
Grid Fields
|   |
| Defined in this column is the name of the screen field. This code can consist of 1 to 10 alphanumeric characters where the first must be a letter. The Adonix reserved words are prohibited. In order to benefit from the trans-class, it must, if possible, have the same name as the field in the table to which it makes reference. A field with the name FIELDNAME defined in the screen with the abbreviation ABV1, can be accesses by the syntax [M:ABV1]FIELDNAME. The name of field is generally coded with 3 characters. These groups are capitalized in the Coding section function. It is recommended that this standard is followed. For custom/specific fields, the field name must start with X_, Y_ or Z_. |
| Indicate the block number where the field should be positioned. |
| Specify the field number. |
|   |
| No help linked to this field. |
|   |
| Specify the data type for the field. As a result of the data type chosen additional information could be requested. |
| Defines the local menu number associated with the field defined on the line. When a field is of the type local menu (from 1 to 255) corresponding to the rank of a title in a table named local menu, stored in the messages table APLSTD. On entry or on display, the following are displayed according to the choices made in the user interface :
The interest of this type of entry is that the list of choices is displayed in the user connection language. Each local menu number characterises the list of available titles. For example, the local menu 1 corresponds to the choice No / Yes in this order. In this particular case, the user interface can also be a check box. |
| Used to define the length of a field when this field uses a generic data type where the length is not fixed. This is notably the case for the types A and DCB. |
| This information indicates whether the field must be entered or not. 3 possible values :
|
| Indicate for a hidden field, if its description must be taken into account in the XML description of the window. The possible values are:
For the hidden fields in the technical section, it is mandatory that this field is set to "all clients", this technology being used to display the XSL graphs. For all other hidden field cases, it is recommended to put "not transferred" except for specific reasons determined on a case by case basis. It should be noted that for the hidden section fields, there are two possible values : "non transferred", "Web services". |
| This field makes it possible to manage the presence of the field in line with the entry mode of a grid. - Record mode (accessible with a right click on the variable at the base of the grid) makes it possible to display/enter a grid line in a window. All the fields of the line that are marked 'Record mode' or 'Record-grid mode' are accessible in a page or several tabs according to the number of fields. - In grid mode, only the fields marked 'Grid mode' or 'Record-grid mode' are accessible. The actions defined for the fields are active in the two modes. |
| If this field is not assigned, the field will always be present. If this field corresponds to a non active activity code, the field will not be generated. Activity codes starting with X, Y, or Z correspond to the custom/specific fields that are not affected by the folder updating. |
| Specify the field dimension. |
| This information indicates whether the field is mandatory or not. |
|   |
|   |
| When the data type is associated with an object, this information is used to automatically create an available tunnel in the contextual menu of the field, that is used to directly access the management of this object. |
| If the response is "yes" to this question, an additional field will be added to the right of the field to display the title of the selected field. This field must be paramaterized in the "title" or "short title" field in the general tab of the associated table. |
| The options depend on the data type (use the search window). This column defines the options applicable on the entry of the field. These options are realized by characters that can be concatenated when several options are required. It is possible to choose these options thanks to a selection window. The available options depend on the field type. A detailed description for all the possible options is available. The combination of these options allows the supervisor to apply a specific entry format for the field. With the contextual menu you can equally indicate the specific format for the field, using the Adonix syntax. The existence of this information is visualised with a "$" in this field. This field is therefore used to enter the options OR an entry format. |
| This field is used to specify the length of the display, in the case where different lengths are required, The entry in this field will then be "scrolling". By default, on the alphanumeric fields with a length greater than 30, the supervisor takes a display length of 30 characters. This entry format is taken into account if no format is indicated in the data type linked to the field and in the field itself). |
| Specify an expression that will be proposed to initialize the field. If the expression is preceded with the character '*', the default value will always be displayed (even if the field is already initialized). |
| If this field is not assigned, the field will always be accessible to a user. If this field is entered, a user will not be able to access the field that is authorized for the corresponding access code. The authorization can give access to consult and/or modify the field. This possibility to restrict the access to a field is reserved to specific/custom and does not require protection by an activity code. |
| The field is defined as being enterable, however in certain conditions it is possible that this should not be the case. The entry condition is a logical expression expressed in the X3 syntax. If the expression is true during the entry, the field will be entered, if not it will be displayed and its value saved. Example : To enter a field if the previous field is a yes : [M]ZONEPREC=2 |
| Use this field to specify which type of graphic object will be used:
On a table block field, the authorized objects are: the check box and the icon. |
| Possibility to add a specific style to a field by the parameterization. This is reserved for customization. The update of this field does not require the protection by an activity code. |
| This field is used to define a control table to verify the entry and in certain cases to have a selection of the possible values. This is reserved for customization. The update of this field does not require the protection by an activity code. |
| All the available parameters for loading the graph with the fields from the grid. These parameters are described in miscellaneous table 915. |
| Used to define the graphical representation of the column in the grid. This information is necessary for the graphs :
|
Grid Actions
|   |
| This grid makes it possible to define the particular actions associated with the field. The possible action types are :
|
| The action code, sent to the action table which specifies the sub-program that is going to be called. However 3 particular codes exist : "STD" , "SPE" and "SPV", which indicate that the action is not catalogued but makes a call to a label that is respectively defined in the "standard" for STD, "specific/custom" for SPE and "vertical" for SPV processes. |
|   |
| This field is used to define the context of the action execution :
|
| This field is available for specific and vertical developments. It is possible to specify:
|
Grid Action parameters
| This part of the screen makes it possible to define the value of certain parameters. |
|   |
|   |
Action icon
In the field section, it makes it possible to automate the creation of the fields in the screen, from the tables specified in the header tab.
In the action section, it makes it possible to access in editing mode the sub-programs of the STD, SPE or SPV actions of the SUBxxx, SPExxx or SPVxxx processes respectively.
Close
By default, the following reports are associated with this function :
AMSK : Screen dictionary
AMSKLIST : List of screens
This can be changed using a different setup.
The following fields are included on the window opened through this button : Block number 1
Block number 2
Close This action is used to copy the definition of the screen to another folder. Caution, it will be necessary to validate the screen in the destination folder. |
This action cannot be accessed. Use the Window management function to view a validated screen. |
This action is used to view the result in Web mode. The screen must have been validated. |
Available on VT screens. Used to display the screen in the form of a log file.
In addition to the generic error messages, the following messages can appear during the entry :
An attempt has been made to save a screen without defining the section.
Each section defined in the screen must have a unique rank. The rank is the unique identifier for the section.
In the grid section definition, it is necessary to indicate in the "bottom of page" column a field for a second tab of the data type ABS assigned to this section.
In the grid section definition, it is necessary to indicate in the "bottom of page" column a field for a second tab of the data type ABS assigned to this section. This field must be the first declared in this section.
These fields in the second tab are assigned to a section not defined in the first tab.
Control on the limit of 32768 active fields, taking into account their dimension and this, by screen. For the grid sections, one field per column is counted irrespective of the number of lines in the grid. For list section, the field dimension is taken into account.
Control on the limit of 240 active fields, without taking into account their dimension, and this, by screen.