Summary
The field is our single data element in Studio, it is named when mapping screens and throughout our definitions and code is treated as a String datatype. While of a simple datatype, fields can be treated differently, and have significant impact on how our applications are generated based on the properties set.
Any Inventu Studio Field with a specific name should have the same length as other field's with the same name, and there are many features in Studio to help you identify the correct name and/or length for a field you are mapping on a screen.
Note that when two fields have the same name, they are carried as different fields in your Studio project, and can have different properties set in different screens and field maps. However, they will become defined in generated code as the same field when the lengths are identical. When two fields have the same name but different lengths, the first one defined in the definition will be generated with the same name you see in Studio, while any subsequent fields are generated with the field name concatenated with the container FieldMap's qualified name.
Roles
| Host | Fields can be protected (labels) or unprotected (entry fields). When entry-capable (unprotected), a field can be simple data to be stored in a database when updated, or can have navigation impact. A field having navigation impact might be a customer number, entered on the first screen in a sequence, and displaying the details for that customer in following screens. In this instance, we have a property set on the field giving it a NavigationUse of keyVariable. |
| WS | Depending on the activity being implemented by a task, a field may be ignored for writing through filtering. |
This completes the major section, Guide to Application Roles and Behaviors
Next Section: Finite State Logic Introduction and Reference
