ATTRIBUTES section

The ATTRIBUTES section describes properties of grid-based layout elements used in the form.

Syntax

ATTRIBUTES
 { form-field-definition
 | phantom-field-definition
 | form-item-definition }
[...]
[END]
where form-field-definition is:
item-type item-tag = field-name [ , attribute-list ] ;
where phantom-field-definition is:
PHANTOM field-name ;
where form-item-definition is:
item-type item-tag: item-name [ , attribute-list ] ;
  1. item-type defines the type of the Form Item.
  2. item-tag is the name of the screen element used in the LAYOUT section.
  3. field-name defines the name of the screen record field.
  4. item-name identifies the form item that is not a form field containing data.
  5. attribute-list defines the aspect and behavior of the form item.
where attribute-list is:
attribute [,...]
  1. The attribute list is a comma-separated list of attributes.

where attribute is:

attribute-name [ = { value | value-list } ]
  1. attribute identifies the attribute of the form item.
where value-list is:
( { value | sub-value-list } [,...])
  1. value is a string, date or numeric literal, or predefined constant like TODAY.
  2. sub-value-list is a set of values separated by comma, to support subset definitions as in "(1,(21,22),(31,32,33))".

Usage

The ATTRIBUTES section is required to define the attributes for the form items used in grid-based containers of the LAYOUT section.

The ATTRIBUTES section must appear in the sequence described in form file structure.

The END keyword is optional.

Every item-tag used in the LAYOUT section must get an item definition in the ATTRIBUTES section.

A form item definition is associated by name to an item tag or layout tag defined in the grid-based container.

In order to define a form field, the form item definition must use the equal sign notation to associate a screen record field with the form item. If the form item is not associated with a screen record field (for example, a push button), you must use the colon notation.

To match the complete structure of a database table record, additional fields can be defined as phantom fields, when no corresponding item tag is used in the layout.

Form item definitions can optionally include an attribute-list to specify the appearance and behavior of the item. For example, you can define acceptable input values, on-screen comments, and default values for fields.

When no screen record is defined in the INSTRUCTION section, a default screen record is built for each set of form items declared with the same table name.

The order in which you list the form items determines the order of fields in the default screen records that the form compiler creates for each table.

To define form items as form fields, you are not required to specify table unless the name column is not unique within the form specification. However, it is recommended that you always specify table.column rather than the unqualified column name. As you can refer to field names collectively through a screen record built upon all the fields linked to the same table, your forms might be easier to work with if you specify table for each field.

When used in a table, some widgets are rendered only when the user enters in the field. For example RadioGroup, CheckBox, ComboBox, ProgressBar.

Example

SCHEMA game 
LAYOUT
GRID
{
  ...
}
END
TABLES
 player 
END
ATTRIBUTES
 EDIT f001 = player.name, REQUIRED,
               COMMENT="Enter player's name";
 EDIT f002 = player.ident, NOENTRY;
 COMBOBOX f003 = player.level, NOT NULL,
      ITEMS=((1,"Beginner"), (2,"Normal"),(3,"Expert"));
 CHECKBOX f004 = FORMONLY.winner,
      VALUECHECKED=1, VALUEUNCHECKED=0,
      TEXT="Winner";
 BUTTON b1: print, TEXT="Print Report";
 GROUP g1: print, TEXT="Description";
END