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

The header is used to identify the screen and provide the general characteristics.

Tab General

Found here is the information linked to the global management of the screen.

Activity code and module

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.

Size 

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.

Template screen

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. 

Associated processes

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.

Definition of the sections

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 rank is 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,Options and 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)

Table section

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.

Referenced tables

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. 

Tab Fields

This tab is used to define all the fields of the screen in a drop-down menu.

Field

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

Description

Possibility to choose one of the three titles for the field stored in the table or an evaluated label or another text.

Section, position

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.

Column

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. 

Type, Menu, Length

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 types documentation, 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:

  • M or MM  corresponding to a local menu where the number is given by the contents of the Menu column. A local menu is a table of titles, entered either in the form of a combi box, or in the form of radio buttons, or (if it is local menu 1 that stores the Yes / No values) in the form of a tick box. The Length column is used to define the display length for the field when it is entered in the form of a combi box.
  • A corresponds to a field of the character string type, where the length is given by the contents of the Length column.
  • DCB corresponds to an amount where the number of figures is defined in the length column (in the form of N.M).
  • L is a long integer, whose length is defined elsewhere.

Entry

Indicate whether the field is entered, displayed, invisible or technical (not taken into account by the Web-services).

Act

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.

Options

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

Mandatory

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

Tunnel, link

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.

Truncation

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.

Default value

Constant or variable used to initialize the field.

Access code

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.

Entry condition

This field is defined as being available for entry, however in certain conditions, it is possible that this field should not be entered.

Graphical object

On a grid section field, the authorized objects are: the check box and the icon. 

Help key word

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.

Style

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.

Control table

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.

 

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.

The fields are organized in a scrolling grid of lines (horizontally and vertically if necessary)

Reports

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.

Specific Buttons

Confirmation

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