Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

> ## Attribute table

> The `ryc_attribute` table has these fields:

> - `attribute_label` — This `CHARACTER` field is the name of the attribute. For SmartObject attributes, this is the same as the name in the property include files. For widget attributes, the name is normally the same as the 4GL attribute name (including hyphens, which are otherwise normally avoided in attribute names).

> - `attribute_group_obj` — This `DECIMAL` object ID points to the attribute group for the attribute.

> - `data_type` — This `INTEGER` field holds the data type of the attribute. As you will see in the description of the fields for the `attribute_value` table, Progress Dynamics supports a list of attribute data types corresponding to the native Progress data types, and stores the attribute value in a field of that data type. This field, therefore, identifies which of the attribute value fields actually holds the value for the attribute. Progress Dynamics Version 1 users might be aware that there was an `ryc_attribute_type` table in Progress Dynamics Version 1. This table has been removed, as the type was really nothing more than the data type, which is now stored here. This is an integer field for performance reasons. The valid values are as follows:

> - 1 — Character
> - 2 — Date
> - 3 — Logical
> - 4 — Integer
> - 5 — Decimal
> - 6 — Reserved
> - 7 — Recid
> - 8 — Raw
> - 9 — Rowid
> - 10 — Handle
> - 11 — Memptr
> - 12 — reserved
> - 13 — reserved
> - 14 — Com-handle

> These values map to the values used in the 4GL and other OpenEdge tools.

> - `attribute_narrative` — This `CHARACTER` field provides a full description of the purpose and use of the attribute.

> - `override_type` — This `CHARACTER` field indicates whether the standard `get` and `set` functions must be used to set and retrieve the attribute value. Normally, these functions serve only to permit other application objects to access the properties of a SmartObject, and for access within the object itself and its super procedures, code can directly access the temp-table that holds the object’s attribute values. In that case, this field is blank. Other values this field can take are `get`, indicating the `get` function does something specific to retrieve the value and must be executed, `set,` indicating the `set` function must be executed to set the value, or `get,set` indicating both the get and the set functions must be executed. If this field has a value, then the functions to get and/or set this property need to be defined. The functions are executed instead of simply accessing the value directly in order to allow them to contain additional logic beyond simply retrieving the value from the temp-table. This is the equivalent of defining the `xp` preprocessors in the property include files of the ADM, but is more flexible in that it differentiates between `get` and `set`.

> Note that in code that checks this value, a `CAN-DO` or `LOOKUP` should be used to ensure the order of the `get,set` pair is irrelevant.

> - `runtime_only` — This is a `LOGICAL` field that defaults to `NO`. If it is set to `YES`, then the value of this attribute should not be stored in the Repository and is only to be added to the attribute temp-table at run time without an initial default value. An example would be an attribute that stores a handle, as the handle has no context outside of the current session, but still needs to form part of the valid attribute list. Other examples are attributes that store the current state of an object, such as `ObjectInitialized`. There would be no point to assigning such attributes a default value. This field is useful in that it permits tools, such as the dynamic property sheet, to filter out attributes that it is not meaningful to assign a value to at design time.

> - `is_private` — This is a `LOGICAL` field that defaults to `NO`. If it is set to `YES`, then the value of this attribute is not intended to be accessed outside of the class where it is defined. This field is also used to filter out attributes from the dynamic property sheet and other tools. Generally, `get` and`set` functions are not defined for private attributes.

> - `constant_level` — This is a `CHARACTER` field and identifies the level at which a property can be modified. The valid values for this are `class`, indicating it can only be specified at the class level, `master`, indicating that the value can be modified at the master level, and `blank`, indicating that there are no restrictions on where the attribute can be assigned a value. This field also assists tools, such as the dynamic property sheet, in filtering out attributes from its display. An attribute, such as `ObjectType`, is defined once for the class and should not be changed in a master or instance. A master attribute, such as the `ObjectName`, should not be changed in an instance. Thus, the dynamic property sheet and other tools disable updates to attributes with a `constant_level` of class when you are defining a master or instance, and disable updates to attributes with a `constant_level` of master when you are defining instance attributes for an object in a container. There is also a `constant_value` field in the `attribute_value` table that is a `LOGICAL` indicating whether further modifications are allowed to the property. The attribute table’s `constant_level` field therefore affects how the `constant_value` flag is set in the `attribute_value` table.

> - `derived_value` — This is a `LOGICAL` field that defaults to `NO`. It can be set to `YES` to indicate that the property value is derived from other properties or other run-time information and doesn’t need to be defined in the attribute temp-table or stored in the Repository. Its value is therefore always set and retrieved using its `get` and `set` functions, which must contain the code needed to determine the value. As an example, the `Visual` class has three attributes that provide information derived from the `getSysColor` built-in function and the `COLOR-TABLE 4GL` object. These are called `color3DFace`, `color3DHighight`, and `color3DShadow`. Because the attribute values are always derived from this system function, there is no need to store the value in the attribute temp-table. Code must always use the `get` functions to retrieve the values.

> - `lookup_type` — This `CHARACTER` field defines the supported means of validating the attribute value for a specific object type. It is used in the dynamic property sheet to determine whether to overlay a combo box, a lookup button, or nothing at all on the attribute value field. Possible values are:

> - `LIST` — If the `lookup_type` is `LIST`, then the `lookup_value` field described next contains a string of possible attribute values in list-item-pairs format. In the property sheet, a combo box containing these values will overlay the attribute value field, so that the user must select one of the defined values for the attribute.
> - `DIALOG` — In this case, the `lookup_value` field contains the relative path and filename of a dialog container where the attribute value can be selected. In the property sheet, a lookup button will overlay the attribute value field. When the user selects the button, the specified dialog box is launched. The user can also enter a value directly without using the dialog.
> - `DIALOG-R` — This is like the `DIALOG` option, but makes the attribute value field read-only, forcing the use of the dialog box. This is necessary for dialog boxes that would return delimited lists that you would not want users to enter manually, or simply to control the value entered.
> - `PROC` — Here, the `lookup_value` field contains the relative path and filename of a procedure to execute to determine the list of valid attribute values in some special way. The Progress `RETURN-VALUE` of the procedure must contain a string of the list-item-pairs used to populate the combo box that overlays the attribute value field.
> - `“”` — Blank indicates a free text entry. The dynamic property sheet simply enables the browse cell in this case so that the user can enter a value.
> - `lookup_value` — This `CHARACTER` field can be used to specify a list of distinct values allowed for this attribute, or it can specify a procedure call that returns a list of values, or it can specify the name of a dialog box, as discussed in the description of `lookup_type`. When it contains a list, the delimiter must be `CHR(3)` rather than a comma, to allow for the possibility that a value might itself contain a comma. The value and format of the `lookup_value` field are dependent on the value of the `lookup_type` field, as follows:

> - If the `lookup_type` is blank, then the `lookup_value` field is blank. Here, there is no restriction on the value the user can enter, and also no assistance in choosing a value.
> - If the `lookup_type = LIST`, then the `lookup_value` specifies the `LIST-ITEM-PAIRS` values. This is a delimited list of labels and values in the form: `label1,value1,llabel2,value2,..`.
> - If the `lookup_type = DIALOG`, then the `lookup_value` specifies the relative path and filename of the dialog box to be run from the property sheet. The dialog procedure must return two `OUTPUT` parameters, the first a `LOGICAL` indicating whether the property was changed, and the second a `CHARACTER` output parameter containing the value, for example, `RUN` `colorChooser.w (OUTPUT lOK, OUTPUT cValue)`.
> - If the `lookup_type = PROC`, then the `lookup_value` field specifies the relative path and filename of an external procedure to be run from the property sheet at initialization, which returns a delimited list of list-item-pairs.
> - `design_only` — If this `LOGICAL` field is set to `YES`, then this attribute is only modifiable at design time, not at run time. The default is `NO`.

> - `system_owned` — If this `LOGICAL` field is set to `YES`, this attribute can only be modified by users with a system-owned flag in their privilege definition. Certain attributes are required for the application to function correctly, and these are set to `system_owned` to prevent accidental deletion. Only users classified as able to maintain `system_owned` information can manipulate this data. In many cases, the actual attribute label must match to a valid Progress-supported SmartObject property.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095