Properties of screen fields: Data tab
Contents
After you have opened a screen in the Screen editor, right-clicked a screen field (a.k.a. entry field) on it and chose Properties in the pop-up menu, the Screen object properties window opens. On the Data tab in that window, you determine the general properties of this particular screen field, like its associated database tag and some interface settings. A screen field is necessary to display the contents of a database field on screen, and to allow the user to enter or edit data in that database field.
Click here for information on how to edit screen object properties in general. And click here to read about how to manage screen fields in the Screen editor.
On the current tab you'll find the following settings:
Fill in the existing data dictionary tag for this screen field. For Axiell Collections you are not allowed to enter a tag which hasn't been defined in the data dictionary (an .inf associated with the data source in which the currently edited screen will be displayed). Note that tags are case sensitive, so tag ab is different from tag AB!
For the above entered tag, choose the data type that corresponds to the way that field is defined in the data dictionary, and which determines what you can enter in this field. Possible data types are:
Data type |
Meaning |
|
Undefined/Text |
Will accept all characters. |
|
Letters |
Will only accept alphabetic characters and spaces. |
|
Numeric |
Will only accept numeric characters. It depends on the Presentation format setting for the field in the .inf if the user must use a dot or comma as the decimal symbol. The numeric value may be preceded by a plus or minus sign. |
|
Integer |
Will accept only whole numbers. The integer value may be preceded by a plus or minus sign. |
|
Date |
Will accept a date and show a user-friendly date picker in Collections. The following notations are allowed depending on how the associated field in the .inf has been defined: |
|
dd/mm/yy |
(e.g. 31/12/94) |
|
dd/mm/yyyy |
(e.g. 31/12/1994) |
|
yy-mm-dd |
(e.g. 94-12-31) |
|
yyyy-mm-dd |
(e.g. 1994-12-31) |
|
yyyy-ddd |
(e.g. 1994-365) |
|
The dd-mm-yyyy is still accepted, but is now deprecated. |
||
Time |
Will accept a time. The only accepted notation is hh:mm:ss (e.g. 23:55:12) |
|
ISBN |
A valid ISBN (number), either with or without punctuation (e.g. 90-03-90201-1 or 978-90-03-90201-6) |
|
ISSN |
A valid ISSN (number), either with or without punctuation (e.g. 0040-9170) |
|
Choose whether this field may be Repeated, Not Repeatable, or Repeatable, values must be unique. Repeated screen fields can have more than one occurrence (Axiell jargon for a field repetition), whilst Not Repeatable can only have one. With Repeated, value must be unique the entered data in every occurrence must be different from the others for the same field.
Your setting must preferably match the Repeatable setting for the associated field in the data dictionary (the .inf), but never set the screen field to repeatable when the .inf field isn't repeatable.
If you have set the length of a repeatable field to 0 in the data dictionary, Collections will automatically use word wrapping. This means that Collections automatically sends a word to the next line of a screen field occurrence (starting a new line if necessary) if the word no longer fits. The reverse happens if you delete text. Collections always reorganises the text to make it fit the entry field as well as possible.
Choose Left, Right, or Center to specify how data in this screen field should be aligned (meaning: to position field data within the horizontal space of the screen field). The Left, Right and Center options speak for themselves. The None option displays the data exactly as it has been entered in the database, including any preceding spaces. The default setting is Left.
When the screen itself is editable, you can still specify for individual entry fields that they are not editable, by choosing Read Only for this property.
Note that it is never possible for a user to change the value of the %0 (record number) tag, even if this property is set to Read and Write. Similarly, a user will be unable to edit the field contents if he or she does not have write access to (the field in) the database. However, a read-only screen field or read-only screen does not prevent a user from changing field contents using the search-and-replace functionality: to block that possibility, making the field in the database definition read-only for certain users is only possible if that field is never filled by an adapl. If an adapl does need to edit the field for every user (like certain management details fields), you could mark the Do not show in lists property for this data dictionary field, although that has the disadvantage that users won't find this field in the Advanced search field list and similar field lists any more.
Validation and Run before/after field adapl
With the Validation drop-down list and the Run before field adapl and Run after field adapl checkboxes you specify what type of input checks Collections should use when data is entered in the current screen field. The Run before field adapl and Run after field adapl checkboxes (which have the same function as the Run adapl before entering this field and Run adapl after leaving this field options in the Validation drop-down list) have been added in Designer 7.4 to allow you to set up a field as both mandatory and validated by an adapl (something that wasn't possible in older versions of Designer).
The options in the Validation drop-down list are the following:
Method |
Action |
None |
Collections does not check whether the field has been filled in or not. |
Field is mandatory |
Upon saving, Axiell Collections checks that some data has been entered in the field, but does not check the actual data. If a field is mandatory and in some record it has multiple occurrences, only the first of them has to be filled in to satisfy the "mandatory" condition, even though your intention might be that all occurrences need to be filled in. (You could program an after-field adapl to check if all occurrences of a field have been filled in.) In Collections, the background of empty mandatory fields will turn pink, to indicate that they still must be filled in. Mandatory autonumbered fields won't turn pink. |
Field must be complete |
Collections checks if the number of entered characters is equal to the length of the associated data dictionary field. |
Field is mandatory in group |
If the current field is part of a field group, then Collections checks that if at least one other field within this group has been filled in, that the current field is filled in too. If no other field in the group has been filled in, then the current field needn't be filled in either. For Axiell Collections, a group must have been defined on data dictionary level: screen level field groups are not supported. |
Run adapl before entering this field |
Collections will use the Field based procedure set for the current database, when the current screen field becomes active (e.g. when the cursor is placed in the entry field). If no Field based procedure has been set, Collections will use the Before screen adapl which may have been set for the current screen. |
Run adapl after leaving this field |
Collections will use the Field based procedure set for the current database, when the current screen field is left (e.g. when the cursor is placed in another entry field, or when the user switches tabs), but only if the field contents has changed. If no Field based procedure has been set, Collections will use the After screen adapl which may have been set for the current screen. |
More about the adapl validation options and checkboxes
Up to and including Designer 7.3, in the Validation property of a screen field you've always been able to set whether the field was mandatory, mandatory in group, had to be "complete" or whether an adapl had to be run before or after entering this field. Two new checkboxes in Designer 7.4, Run before field adapl and Run after field adapl, now expand your field validation options by allowing you to set up a field to be both mandatory (or must be complete) and be validated by an adapl. The advantage of being able to combine these two types of field validation is if you really need to use an adapl to validate data entry while the field must be mandatory too, then from now on you no longer need to write before-storage adapl code to check whether the field has been filled in at all (and cancel saving the record if it hasn't): the normal Field is mandatory setting (or Field must be complete or Field is mandatory in group settings) will take care of that type of validation.
Of course you won't have to change the properties of any existing screen fields nor will you have to rewrite any adapls if you have a functioning application, but for new screen fields or existing screens fields that you'd like to turn into mandatory, adapl validated fields the extra options will come in handy. For example, suppose you have an objects database in which object numbers are mandatory but do not need to be unique, while the user must get a warning each time he or she enters an object number which already exists in the database. This requires after-field validation by adapl (for which you'll have to write the code), but it also requires you to set the field to be mandatory.
The different validation options are always executed in a particular order: validation of the Mandatory requirement always takes place first. If it fails (because the field is still empty), the user will be warned if appropriate and any after-field validation adapl won't be executed. If it succeeds, the after-field adapl runs.
The Validation drop-down list still contains the old Run adapl before entering this field and Run adapl after leaving this field options for backwards compatibility. You'll never have to set both the adapl Validation property and the comparable adapl checkbox: unless you're willing to rewrite the relevant adapl, just leave the Validation property as is, if existing fields have been set to run an adapl, and do not mark the new checkboxes. Only for new fields, preferably use the checkboxes for adapl validation and set the Validation property to any of the other (non-adapl) options, if you need such combined validation.
A regular expression is sort of a template that prescribes how the contents of a field should be formatted. You can use it to indicate what characters Collections should accept in the input and what characters should appear at what position. Click here for the full Help topic about regular expressions.
If the current screen field is filled in by the user, it will be validated to any regular expression you provide here, when the field is left.
You can use this functionality if user input in a certain field must adhere to particular rules, like an object number that must always start with two alphabetic characters, followed by exactly six numbers for instance.
Foreground & Background colour
Foreground and background colours for entry fields are not supported by Axiell Collections.
Mark the Legacy only checkbox (available from Designer 7.3) to prevent this screen field from showing up when Axiell Collections displays the current screen. (For display in a legacy Adlib application it doesn't matter whether you mark the checkbox or not.) This allows you to present the same screen with a more or less limited set of fields in Axiell Collections. A typical use would be to exclude the read-only fields at the top of most screens designed for Adlib for Windows from displaying in Axiell Collections.
See the Excluding screen fields from Axiell Collections applications topic in the Designer 7.3 release notes for more information about Axiell Collections and its relation to the now obsolete Adlib for Windows.