|
Using the ‘Value’ property when changing a field to the value of a component
All fields use 'Value' as their default property. This means the command
SET COM(#MyComponent) Value(#MyField)
is exactly the same as
SET COM(#MyComponent) Value(#MyField.Value)
Also, fields in the LANSA repository are used to define the class of a visual LANSA Components in a number of ways.
| As a visual component: |
DEFINE_COM CLASS(#MYFIELD.Visual) |
| As a non-visual component: |
DEFINE_COM CLASS(#MYFIELD) |
| As a Property: |
DEFINE_PTY NAME(MyProperty) GET(*Auto #MYFIELD) |
| Or as a Property, defined with a DEFINE_MAP within a Property, Method, or Event Routine: |
DEFINE_MAP FOR(*INPUT) CLASS(#MYFIELD) NAME(#MyProperty) |
When a repository based field is used to define the class of these components, they inherit 'Value' as their default property as well. This makes it quite possible to use that component in regular RDML commands just like fields. For example: The command:
CHANGE FIELD(#MYFIELD) TO(#MyProp)
is exactly the same as:
CHANGE FIELD(#MYFIELD) TO(#MyProp.Value)
However, if the name of the component is more than 9 Characters in length, the function checker will produce an error, "Syntax or logic errors found in syntax of TO Parameter in CHANGE command," on the command without the '.Value' specified.
For this reason, we strongly recommend that the 'Value' property identifier always be used when accessing the value of a component within an RDML command.
|
