These pages refer to legacy Hydra and Lycia 1 features.
The functionality described here does not embrace all the functionality provided by Lycia 3.
If you use Lycia 3, please, turn to other sections of this online documentation.
These pages refer to legacy Hydra and Lycia 1 features.
The functionality described here does not embrace all the functionality provided by Lycia 3.
If you use Lycia 3, please, turn to other sections of this online documentation.
A 4GL form specification file is a source file (with file extension .per) that you can create with a text editor or within LyciaStudio. This file comprises three required sections (DATABASE, SCREEN, and ATTRIBUTES), and may also include four optional sections (TABLES, INSTRUCTIONS, KEYS and ACTIONS). If present, these seven sections must appear in the following order:
DATABASE section. Each form specification file must begin with a DATABASE section identifying the database (if any) on which the form is based. This can be any database that the current database server can access, including a remote database.
SCREEN section. The SCREEN section must appear next, showing the dimensions and the exact layout of the logical elements of the form. You must specify the position of one or more screen fields for data entry or display as well as any additional text or ornamental characters.
TABLES section. If it is present, the TABLES section must follow the SCREEN section. This section lists every table or view that is referenced in the ATTRIBUTES section. If a table requires as a qualifier, the name of an owner or of a database, the TABLES section must also declare an alias for the table.
ATTRIBUTES section. The ATTRIBUTES section describes each field on the form and assigns names to fields. Field descriptions can optionally include field attributes to specify, for example, the appearance, acceptable input values, on-screen comments, and default values for each field.
INSTRUCTIONS section. The INSTRUCTIONS section is optional. It can specify screen arrays and non-default screen records and field delimiters.
KEYS section. The KEYS section is optional. It can specify toolbar and context menu items based on key events.
ACTIONS section. The ACTIONS section is optional. It can specify toolbar and context menu items based on action events.
Each section must begin with the keyword which is its name. After you create a form specification file, you must compile it. The form driver of your 4GL application can then use 4GL variables to transfer information between the database and the fields of the screen form.
This is the syntax of a ’ form specification:
The next seven sections of this chapter identify the keywords and terms that are listed in this diagram and describe their syntax in detail.
The following example illustrates the overall structure of a typical form specification:
DATABASE cms
SCREEN {
Querix Demo CMS V.0.4 - Login
\gp--------------------------q \g
\g| | \g
\g| \gUser\g \gID: [f1 ] \g| \g
\g| \gPassword: [f2 ] \g| \g
\g| | \g
\gb--------------------------d \g
User\g \gID Admin
Password Admin
[f11 ][f12 ]
}
TABLES
users
ATTRIBUTES
f1=users.name, comments="Enter your User ID", upshift;
f2=users.password, comments="Enter your Password", password, upshift;
f11=formonly.f11, config="Return OK", widget="button";
f12=formonly.f12, config="Break Cancel", widget="button";
INSTRUCTIONS
DELIMITERS "[]"
KEYS
F2="OK" ORDER 1
F3="Cancel" ORDER 2
F12="Exit" ("icon16/exit01.ico") ORDER 99
HELP="Help" ("icon16/help01.ico") ORDER 101
ACTIONS
act_edit="Edit" ("icon16/record_edit01.ico") ORDER 5
In this example, the screen form has been designed to display columns from a table in the cms demonstration database and includes all five of the required and optional sections that are described in the pages that follow.