Development > Script dictionary > Screens > Screens 

This function is used to create and modify screens in the software by defining their description in a table. A screen is in reality a tab or the upper section of a window in which several tabs can be found. The confirmation of this description is then used to create the screen source and to compile it in the different languages in which the folder is generated.

Each screen is organized in sections and each section contains one or more fields. A section is a field that can be entered, displayed or hidden.

A screen is defined by its code and its abbreviation. Whilst the code is unique in a folder, the abbreviation may not be ; it is nevertheless necessary to take care that it is not possible to simultaneously open two screens having the same abbreviation : it is therefore important that the different tabs for a single object have different abbreviations. For an object with the code XXX, the header screen is called XXX0, and the different tabs XXX1, XXX2, …, XXXn ; this standard is strongly advised but it is however not mandatory.

It is possible to insert graphs into X3 screens, by authorizing a graphical representation in a grid section.It could be a simple or multiple graph, in the form of a Gantt graph or based on an XSL component created in the dictionary of the screen components

Web pages can also be inserted, by creating "browser" sections, and using the dictionary of the screen components.

It is possible to define screens in a VT format.

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Screen management

Header

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.

  • field ABRMSK

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.

  • Title (field ZINTMSK)

No help available for this field.

  • Templ. screen (field MDL)

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

 

Tab General

Presentation

This tab is namely used to identify the sections forming the screen.

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 position, line, column are used to position the sections with respect to the others. It is necessary to simulate a grid on the section design, then indicate the positioning for each section by means of the coordinates (line.column) of its upper left angle, the occupation by means of the number of lines and the number of columns in this fictional grid. For instance:

GESAMK_001.jpg

Section

Position

Line

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

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.

  • Module (field MODULE)

Module belonging to the setup. This field is used to specify whether the screen has to be created in the folder database. It is specified when the module linked to the screen is active in the folder.

  • Size (field TYPMSK)

The screen is firstly defined by its type, which can be :

  • Header and tab are particularly used in the object, inquiry management in a "Window entry" template.
  • Dialogue box is used in the window entry template.
  • Full screen is used in a grid object and in a "Window entry" template.
  • Full screen with left list is used in a simple object with 1 single screen and in a "Window entry" template.

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.

  • field NBRLIG

 

  • field NBRCOL

 

Scripts

  • Standard script (field TRTSTD)

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.

  • Vertical script (field TRTSPV)

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.

  • Specific script (field TRTSPE)

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.

Table Blocks

  • No. (field NOBLOC)

 

  • Block title (field ZTITBLOC)

The title of a section is optional, it will appear in the upper part of the frame. This text is translatable. It can be evaluated.

  • Block type (field TYPBLOC)

This type of block defines the presentation of the fields for the interior of a block.

  • Grid : The fields are organised in a scrolling grid of lines (horizontally and vertically if necessary)
  • List : list of fields independent one from another
  • Text : Display of the fixed background texts, without needing to be entered
  • Hidden : Declaration of a hidden list section. Used to include a screen of hidden technical fields used by the processes linked to the screen.
  • Flash : to use the portal views (given externally to the function)
  • Office : for Excel, Word, Powerpoint document
  • Browser : for web page
  • HTML editor : reserved for the entry of the documentation
  • Technical : for XSL components
  • Business Intelligence : for the execution of a BO report (reserved for the supervisor)
  • Position (field POSBLOC)

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.

  • Line (field LINBLOC)

 

  • Col. (field COLBLOC)

 

  • High (field HTBLOC)

If necessary, these fields are used to indicate a number of columns and minimum number of lines for a grid section.

  • Width (field LGBLOC)

 

  • Sequence (field RANG)

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         
It is therefore strongly advised to not modify the rank of the section in the screen definition.

  • Length (field LNGLIB)

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.
If this field corresponds to a non-active activity code, the fields for this block will not be generated.

  • Line (field NBLIGT)

For a section of the grid type, this field type indicates the maximum number of lines in the grid.

  • Options (field OPTION)

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:

  • K : Previous & next line in entry mode
  • A : Cancelation of a line
  • D : Cancelation of a group of lines
  • R : Addition of lines at the end of the grid
  • I : Insertion of lines
  • S : Cut
  • B : Copy
  • C : Paste
  • T : Loading of all the lines in the grid
  • ? : Search
  • + : Column justification
  • = : Automatic record mode
  • 1-9 : Number of fixed columns (from the 1st column)

  • Parameter (field BASPAG)

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 (field BLOCTYPT)

Representation of the "grid" section in the screen :

  • Character : no graph associated with the grid
  • Grid or graph : graph and grid are alternatively present at the request of the user
  • Grid or graph : graph and grid are present in the screen
  • Graph: only the graph is present on the screen ; the grid is not accessible

For the last 3 values, a screen for the "Graphical parameters" is accessible from the contextual menu.

  • Grid block (field DETBLC)

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

Table Reference tables

  • No. (field NOFIC)

 

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

 

Functions accessed by right click on the grid

URL definition

Available for a section of Browser type.

Enables the entry of 1 to 3 URL codes. The latter must be declared in the screen component function.

Definition of Office sections

Available for an Office type section.
Used to define the Office document type: Word, Excel, Powerpoint, or Universal

 

Fermer

 

Tab Fields

Presentation

This tab is used to define all the fields of the screen, then, in the following two grids, for each field, the processes to be run as well as the associated parameters.

Action section

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.

Parameters for action section

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.

Close

 

Fields

The following fields are present on this tab :

Table Fields

  • No. (field NUMLIG)

 

  • Field (field CODZON)

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_.

  • Block (field NUMBLOC)

Indicate the block number where the field should be positioned.

  • Position (field NOZONE)

Specify the field number.
For a grid type block, the fields are placed from left to right in ascending order of their numbers.
For a list type block, the number indicates the line number in the block (1= top line). To place several fields on the same line you must indicate the order in the decimal part. For instance, 1.2 indicates the second position of the first line.

  • Title (field ZINTIT)

Specify a title that will be placed to the left of the field (or on top in grid mode). Possibility to choose one of the three titles for the field stored in the table or an evaluated label or another text.

  • Col. (field PDSZON)

No help available for this field.

Specify the data type for the field. As a result of the data type chosen additional information could be requested.

  • Menu (field NOLIB)

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 :

  • either a title can be chosen in a scrolling list commonly called a combo box
  • or a list of buttons.

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.

  • Length (field LONG)

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.

  • Input (field SAIAFF)

This information indicates whether the field must be entered or not. 3 possible values :

  • Enter : Normal
  • Displayed : The field is never entered but always visible.
  • Hidden : The field is present only as a variable of the screen, but not entered or displayed.
  • Transmission (field TRANSM)

Indicate for a hidden field, if its description must be taken into account in the XML description of the window. The possible values are:

  • No transferred: not taken into account. (corresponds to the technical field V140)
  • All clients : taken into account by the client and Web services.
  • Web services :taken into account by the Web services only. (corresponds to the hidden field V140)

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".

  • Method (field MODE)

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.

  • Dim. (field DIME)

Specify the field dimension.
This dimension is automatically assigned in the case of a drop-down grid.
This dimension can also be automatically assigned in the case where the field activity code carries a dimension.

  • Mandat (field OBLIG)

This information indicates whether the field is mandatory or not.
For an alphanumeric field, mandatory signifies that the zone cannot be empty.
For a numerical field or date type, mandatory signifies that a nil value cannot be entered.

  • Tunnel (field TUNNEL)

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.

  • Link (field LIEN)

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.

  • Options (field OPTSAI)

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.

  • Truncation (field OPTLNG)

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).

  • Default value (field VALDEF)

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.

  • Entry condition (field CONSAI)

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

  • Graphic object (field TYPGRAPH)

This field makes it possible to specify the type of graphic object that will be used :

  • Check box : Only for a field of type Yes/No.
  • Radio buttons : Only for a field of type local menu with a restricted number of choices.
  • Spin button or slider : Only for the numeric fields.

On a field in the grid section, 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.

  • Setup (field ACHPARG)

All the available parameters for loading the graph with the fields from the grid. These parameters are described in miscellaneous table 915.

  • Representation (field CHREPR)

Used to define the graphical representation of the column in the grid.

This information is necessary for the graphs :

  • Default : the representation defined for all the graph is used
  • Bar
  • Line

Table Actions

  • No. (field NOAC)

 

  • Type (field TYPACT)

This grid makes it possible to define the particular actions associated with the field. The possible action types are :

  • Before-field : Action before all entry or display of the field. It can be used, for example, to define the format of the field.
  • Init_button : used to define the button names in the contextual contextual.
  • Init: Used to initialize a field.
  • Before_entry : Action carried out before each entry. For example it can be used to position mkstat and so not enter it.
  • Control : Makes it possible to test the validity of the field.
  • After-field : Carried out after the control if this is valid. Makes it possible for example to assign or to display other fields.
  • After-modif : Ditto but is not started unless the field has been modified.
  • Selection : Started by the F12 key.
  • Button 1 : Triggered by the F9 key (reserved for the tunnels)
  • Button 2 to 20 : The F4 key makes it possible to have a list of contextual menus.
  • Before_line : Uniquely for the scrolling menus, making it possible to so something each time line modification is started.
  • After_line : Uniquely for the scrolling grids, making it possible to do something after each line entry.
  • Click : Only for the icon fields

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. 

  • Title (field ZINTITACT)

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. 

  • Execution (field EXEACT)

This field is used to define the context of the action execution :

  • Interactive : on-line entry.
  • Import / Web service : loading of the record web service or import mode. The execution of the actions on the fields is carried out when all the fields are entered.
  • Always : in all cases.
  • Deactivation (field DISACT)

This field is available for specific and vertical developments. It is possible to specify:

  • Concerning an SPV action: the deactivation or not of the STD action of the same type
  • Concerning an SPE action: the deactivation or not of the SPV action and/or the STD action of the same type

Table Action parameters

  • No. (field NOPA)

This part of the screen makes it possible to define the value of certain parameters.
These parameters correspond to the actions that are specified for a field (for example for post code control action, it is necessary to define the country code field and the city/town field). Warning, comply with the parameter type specified in the help.

 

  • Value (field VALPAR)

 

Close

 

Functions accessed by right click on the grid

File Field Selection

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.

Enter ticket

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.

 

Fermer

 

Reports

By default, the following reports are associated to the function :

 AMSK : Screen dictionary

 AMSKLIST : List of screens

This can be changed by a different setup.

Specific Buttons

This function is used to generate the *.msk in the ECR directory. This file is independent of the language. It contains the actions to be executed, the formats. The validation is used to generate the automatic processes linked to the screen (W0xxxxxxx for the import, W1xxxxxxx for the interactive, where xxxxxxx is the screen code).

The following fields are present on the window opened through this button :

Block number 1

  • field OBJET

 

  • field CLES

 

Block number 2

  • From folder (field DOSORG)

This field is used to define the folder from which the record is going be copied. The possible syntaxes are described in the dedicated appendix.

  • All folders (field TOUDOS)

This option is used to copy the record to all the folders defined in the dictionary (ADOSSIER table from the current solution).

  • To folder (field DOSDES)

This field used to define the folder in which the record is going be copied. The possible syntaxes are described in the dedicated appendix.

Close

This button is used to copy the definition of the screen to another folder. Attention, it will be necessary to validate the screen in the destination folder.

This button is used to view the result. The screen must have been validated.

This button is used to view the result in Web mode. The screen must have been validated.

Menu Bar

Window / View VT

Available on VT screens. Used to display the screen in the form of a log file.

View / Icons

View / Icons for BOMs

Control / Action parameters

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

No section defined

An attempt has been made to save a screen without defining the section.

2 sections exist with the rank n

Each section defined in the screen must have a unique rank. The rank is the unique identifier for the section.

xxxxxx : variable at the bottom of the grid is non-existent

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.

The bottom of grid variable must be the first of 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. This field must be the first declared in this section.

n : Non-existent section

These fields in the second tab are assigned to a section not defined in the first tab.

Number of fields too big ( >= 32768 )

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.

Too many lines ( >= 240 )

Control on the limit of 240 active fields, without taking into account their dimension, and this, by screen.

 

Tables used

SEEREFERTTO Refer to documentation Implementation