|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Product | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Support | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Everything Else | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Field Shading in Helix Applications | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Introduction | Helix views allow data rectangles to be shaded to indicate whether the data seen is a default or an invalid value. These features are controlled by the Shade Defaults and Shade Invalid Fields menu selections found in the √ menu. They are both active by default when a new view is created. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| About Defaulted Fields |
When working on an Entry view, a field can contain a default value that is not yet stored in a field. Typically a default value is supplied by putting both an abacus and a field in the same data rectangle. The field is where the data is actually stored, but the abacus provides a default value, to save the user from having to type into the field. A common use of a default field is in a Record Number field, where each record should contain a unique number. By creating an abacus that determines the maximum number previously used and adding one to it (typically referred to as a Max+1 calculation) and including that in the same data rectangle as the Record Number field, the entry view can provide a default value for the next record, saving the entry clerk time and reducing errors. Of course, the default value is only a suggestion: the user is usually free to type in any value they choose to. Either way, when the user actually enters the record, whatever is present in the data rectangle is stored in the field itself. At this point it ceases to be a default value. For a record that has already been entered, presence of defaulted fields indicates that the field is currently undefined in the record being viewed, and that replacing the record will store the default value in the field where it is seen. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| About Invalid Fields |
Helix allows the collection designer to validate fields to make sure the value entered meets certain criteria. A field that falls outside the required criteria is said to be invalid. Helix will not allow a record to be entered or modified if the entry would add invalid data to it. (Invalid data, already present on a record, can remain in the record as long as the user does not attempt to modify the invalid fields.) A common use of a validation is in a Record Number field, where each record should contain a unique number. By creating a validation that ensures that every record contains a unique record number (typically using a calculation with the Unique tile), the entry view can be prevented from creating multiple records with the same record number. Validation and defaulted fields are typically used together to make data entry faster and more error-free. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| About Field Shadings |
When a view has the Shade Defaults or Shade Invalid options turned on, Helix changes the look of the field to indicate when a field is defaulted or invalid. Each condition has its own visual indicator. If either indicator is not desired, the collection designer can turn the shading off via the √ menu. Turning off shading does not change the effect: defaulted fields are still defaulted and invalid fields are still prevented in data entry. Only the visual shading is disabled. (Note however that invalid field shading is also displayed on list views. In this case, turning the shading off can also speed up the list, as Helix then does not need to test the field validity at all.) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Shaded Fields in Classic & OS X |
Classic Helix (OS 9 and earlier) uses QuickDraw to overly a dot pattern: light for defaulted fields, heavy for invalid fields. (See the table below.) QuickDraw is not available in OS X, so in that environment defaulted and invalid fields are shaded with color (light green for defaults, light red for invalid data). (These colors can be changed by editing the HxDefaultBackgroundColor & HxInvalidBackgroundColor preferences. See the built-in Help in Helix for more information on editing preferences.) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Shading Tables |
These tables show the availability of shading for the various data types and the shading appearance in Classic and OS X.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Notes |
To every rule, there must be exceptions:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Related Articles |
Optimization of Lists Using the Shade Invalid Fields Command |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||