Most EGL parts have a set of properties that are used to create appropriate output at generation time. You set those properties in a set-value block, which is an area of code that is shown later in the current topic and is described more fully in Set-value blocks.
If a part is itself a subtype, additional properties are available. A program of type textUI has a property called alias, as well as a property called inputForm. The latter identifies a text form that is presented to the user before the program logic runs.
DataItem IDPart CHAR(9) { minInput = 9, // requires 9 input characters isDigits = yes, // requires digits columnName = "SSN" // is related to a column }
myVariable IDPart;
You can declare that variable in a composite part such as a record part or directly in a logic part such as program. In every case, the part type determines whether a given property is used.
In the current example, the property columnName is used only if the variable is declared in a record of type SQLRecord. The two validation properties are used only if the variable is declared in a user-interface part such as a pageHandler.
myVariable IDPart { isDigits = no };
In this example, the property minInput is unaffected by the override, and the property columnName is ignored.
A property cannot be accessed at run time. When you create variables that are based on an SQL record part, for example, the logic that you write cannot retrieve or change the names assigned to the tableNames property, which identifies the SQL tables that are accessed by the record. Even if you override a property value in a variable declaration, the value that you specify at development time cannot be changed by your logic.
The lack of runtime access to a property value means that when you assign the content of a variable or use the variable as an argument, the property value is not transferred along with the content. If you copy data from one SQL record to another, for example, no change is made to the specification of which SQL tables are accessed by the destination record. Similarly, when you pass an SQL record to an EGL function, the parameter receives field content, but retains the SQL-table specifications that were assigned at development time.
Predefined EGL parts such as ConsoleField may include both properties and predefined fields. Unlike properties, the fields (sometimes called attributes) are available at run time. The logic that you write can read the field value and in many cases can change the field value.
If you make multiple assignments to the same field or property in a set-value block, the last assignment takes effect. That rule also applies to fields of complex properties, which are described in the next section.
myService myServicePart { @EGLBinding {commType="DIRECT", serviceName="myService", servicePackage="my.useful.service"} }
Neither a complex property nor its fields can be accessed at run time.
Related concepts
References to variables in EGL
Set-value blocks
Related concepts
References to variables in EGL
Set-value blocks
Related tasks
Declaring a record that redefines another
Related reference
Form part in EGL source format
Primitive field-level properties