Windows

• Window (field WIN)

The window code must be composed of 1 to 10 characters (letters or numbers but must start with a letter). It is recommended to name a window linked to an object Oxxx where xxx is the object code. The Adonix reserved words are prohibited.

• Title (field ZDES)

Destined notably to figure in the reports and the screens in which the record code can be entered or selected. This text is used to give a clear description to the record concerned.

• Window template (field MDL)

This field is used to define the windows that are never validated. In the same way if a window contains a template screen it will not be validated.

• Active (field ENAFLG)

This field makes it possible to deactivate the window. If this window is part of a group of transactions linked to the same object, it will no longer appear in the transaction button for the object management.

• VT window (field FVT)

This flag indicates that this window is in the VT format.

• Activity code (field CODACT)

An activity code is used to:

• make optional an element in the dictionary if the value associated with the activity code is null.
• identify the specific/custom elements if they are marked with a code starting with X, Y or Z.
• size a maximum number of lines when the activity code marks elements from a grid.

In this way, if the activity code is disabled, the marked element will not be useable, and the associated code (if any) will neither be generated nor can be activated.

• Module (field MODULE)

Specify the module using this window. If the window is used by several modules, indicate "supervisor".

• Window type (field WINTYP)

This field indicates the context in which the window is called to the supervisor :

  Object : window called by object management.

  Inquiry : principal window called by an inquiry.

  Inquiry criteria : criteria widow called by an inquiry.

  Miscellaneous : used to specify all other call contexts for this window.

• Display (field TYP)

Used to specify the type of window :

• Full screen (inpbox)
• Dialogue box (independent window not necessarily full page, can contain buttons, menu, left lists)
• Mess sage box (independent window without menu, without left lists, without tunnel)

• Access code (field ACS)

This access code makes it possible to prohibit access to the window (transaction) for certain users. If the field is assigned, only those users who have this access code in their profile can access this window according to the rights accorded.

• Object (field OBJ)

It is possible to define several windows for the same object. In this case, to distinguish between the windows, it is necessary to define the transactions. In object management, the transaction button allows the visualization of the titles of the accessible transactions. The variable GFLAG makes it possible to define a transaction before returning to the object management. Transactions can be defined without there being a defined object. In this case, it is necessary to 'manually' manage the different transactions.

• Transaction (field TRN)

• Transaction title (field LIBEL)

• Inquiry (field CNS)

This field is to be entered for a window of the type enquiry or enquiry criteria.

• Header screen (field MSKENT)

Give the screen name that is positioned above the tab(s). When there is only a single screen, it is to be defined as a tab.

• Tabs (field NOMMSK)

Indicate the name of the management screens in the display order of the pages. It is necessary to have at least one screen in the window.

For the windows linked to the object but coming from the transactions (transaction code entered), this information comes from the transaction. Warning! Nothing is gained from modifying the tab codes because this information will be re-generated at the time of the transaction validation.

• Tab titles (field ZINTONG)

• Sequence (field ROWMSK)

The rank is used to order the tabs in the window. It is initialize to 5 in 5. The addition of a specific/custom screen must be made at the end of the grid ; it is the rank that will be used to place it in the required place in the window.

• Visible (field FLGMSK)

If this field is not ticked, the tab and its fields will be invisible. This function makes it possible to use the same object management either for a complete entry (window with all the tabs) or for a rapid visualisation masking certain objects.

When this tab is set to be invisible, the class [M] for the screen is present.

• Activity (field ACTMSK)

Once a tab is deactivated by an inactive activity code, the class [M] for the screen is absent.

• Type (field TYPBOUT)

Local menu that is used to identify the button in the menu or the menu line. The button is automatically positioned at the bottom of the window ; the menu is placed at the top of the window following File/Print/...

• Code (field CODBOUT)

This is the button code used in the programming of the actions AVANT_BOUT, EXEBOUT, etc.. Similarly, the menus are identified, by being defined defined on 2 levels, then the menu lines. The lower level code takes the first character(s) of the upper level. Example, menu A is subdivided into menus AB and AC, themselves sub-divided into AB1 and AB2, then AC3 and AC4.

The characters authorised for the use with specific/custom are all lowercase letters.

The characters authorised for the standard are uppercase letters as well as numbers. Warning, it is necessary to take into account the restriction defined below for the windows linked to an object or an enquiry. In fact, it is not possible to use the codes already used for the supervisor buttons.

The codes available for the object window buttons are : BGOUVYZ0123456789

The codes available for the principal enquiry windows buttons are : ABHIJKMNOPQSTUVWXYZ12345678

• Management (field VALBOUT)

• Non validating : the controls on the field are not executed before using the button or the menu.
• Validating : the button is executed if all the controls on the fields are valid.

• Button text (field ZTXTBOUT)

Name of the button, of the menu or the line in the menu.

It is possible to leave this text empty to define a separator line in the menu.

• Action (field ACTBOUT)

The action code makes reference to the actions dictionary, containing both the process code and the list of the parameters. In the window management, the value for these parameters is to be entered in the 2nd grid and thus for each action.

When the process triggered by the button or the menu does not open the window and only in this case, it is possible to reference the STD, SPE or SPV in the action code. For a window object, for example, the sub-program EXEBOUT or STATUT for the process SUBxxx, SPExxx or SPVxxx will then be executed ( xxx being the object code).

• Activity (field CODACTBOUT)

An activity code is used to:

• make optional an element in the dictionary if the value associated with the activity code is null.
• identify the specific/custom elements if they are marked with a code starting with X, Y or Z.
• size a maximum number of lines when the activity code marks elements from a grid.

In this way, if the activity code is disabled, the marked element will not be useable, and the associated code (if any) will neither be generated nor can be activated.

• Parameter definition (field PARAM)

• Value (field VALEUR)

When located on a line in the actions grid, the parameters for this action (arising from the actions dictionary) are displayed in order that their entry of an expression gives the value of the parameter at the time of the call. This expression can include constants, functions and on-line variables at the time of the call.

• Buttons (field LIBSTD)

• Code (field CODE)

• Management (field VSTD)

• Y/N (field BSTD)

This is used to make a standard button available or not.

• Actions (field ACTSTD)

The action code makes reference to the actions dictionary, containing both the process code and the list of the parameters. In the window management, the value for these parameters is to be entered in the 2nd grid and thus for each action.

When the process triggered by the button or the menu does not open the window and only in this case, it is possible to reference the STD, SPE or SPV in the action code. For a window object, for example, the sub-program EXEBOUT or STATUT for the process SUBxxx, SPExxx or SPVxxx will then be executed ( xxx being the object code).

• Parameter definition (field PARAM)

• Value (field VALEUR)

When located on a line in the actions grid, the parameters for this action (arising from the actions dictionary) are displayed in order that their entry of an expression gives the value of the parameter at the time of the call. This expression can include constants, functions and on-line variables at the time of the call.

• Display (field DERLU)

This box is used to activate/de-activate the Last read left list.

• In first position (field FIRLIS)

This field makes it possible to place the left list 'Last read' in first position.

• Object (field OBJLIS)

This field corresponds to an object. This object can be of the type 'Browser', specially dedicated to a left list.

• Title (field ZINTLIS)

It is the title that will appear in the left list.

• Index (field CLELIS)

This field is used to define an index for the principal file for the display in the left list and in the selection windows. If this field is empty, it is the first index in the table that is used.

• Sign (field ORDLIS)

This field is used to define the direction from moving through the principal table for the display in the left list and the selection windows for the object.

• List type (field TRELIS)

• simple
• hierarchy : When the key chosen for the let list is composed of several parts, the list presents only the first part of the key initially. By double clicking on one of the values of the key there is the possibility to explore the sub-values of the key and thus through the number of levels of existing sub-keys. When all the key levels are explored, a record can be selected from the table.
• simple picking : possibility to select one or more elements.
• picking : picking from a hierarchy list
• Recursive : parent element with daughter elements to next parent elements with daughter elements

• Browser (field BROLIS)

If this field is set to yes, the double click in this left list will be used to display the selected record, in the right hand part of the screen.

• Preloading (field CHGLIS)

This field is used to manage the pre-loading of the left list on start-up.

• No: no pre load.
• Partial: pre load following the number of elements planned in the parameters (GNBGAUCHE).
• Total : all the table is pre-loaded.

• Abbr. (field ABRLIS)

Abbreviation for the table used by the left list. There is the possibility to have 2 browsers for the same table. Warning, it is necessary to specify in this browser (object dictionary / selection object) the abbreviation followed by the field in the expressions for the listed elements. Example : object ORD.

• Sequence (field ROWLIS)

The rank is used to order the left lists in the window. It is initialize to 5 in 5. The addition of a specific/custom left list must be made at the end of the grid ; it is the rank that will be used to place it in the required place in the window.

• Activity code (field ACTLIS)

An activity code is used to:

• make optional an element in the dictionary if the value associated with the activity code is null.
• identify the specific/custom elements if they are marked with a code starting with X, Y or Z.
• size a maximum number of lines when the activity code marks elements from a grid.

In this way, if the activity code is disabled, the marked element will not be useable, and the associated code (if any) will neither be generated nor can be activated.

• Pointers (field FLELIS)

Set to yes by default. In this case, the arrows appear in the left list header and make possible the pagination. There is the possibility to prohibit the pagination, for example for the complex non developed paginations or where too much system resources are required.

• Link expression (field EXPLIS)

Expression necessary for recursive lists in order to make the link between the mother and daughter records.