Before you look at the code for this example that actually creates and manages the dynamic objects, this section summarizes some basic principles of setting up dynamic field-level objects.

Frame parenting

You can place a dynamic field-level object in either a static or a dynamic frame. To do this, assign the frame handle to the FRAME attribute of the object. For a field-level object, there is also a PARENT attribute. Remember that there is a field group object that acts as the immediate container for field-level objects, in effect in between the frame and the individual objects. The PARENT attribute points to the field group, not the frame. the AVM automatically puts the object into a field group when you assign its FRAME attribute and also when you assign the object a default tab position, if it can receive input.

Object positioning

To arrange objects in a frame, you must explicitly position each one by setting the appropriate vertical (ROW or Y) and horizontal (COLUMN or X) attributes. However, the AVM does assume the topmost and leftmost position in the frame if you do not set a placement attribute for the object. This means that, if you place multiple dynamic objects into a frame without positioning them properly, they all wind up on top of one another.

Object sizing

You can size an object, depending on its object type and data type, using either the various height and width attributes or the FORMAT attribute. Because of the imprecise nature of width calculations for values displayed in variable-width fonts, you might have to adjust either the format or the width to be appropriate for the values you are displaying. This is no different than for static objects in a graphical environment. Be aware that a FORMAT of "X(20)" is not necessarily the same width in terms of screen real estate as a WIDTH-CHARS of 20. Generally, the AVM uses a formula for calculating a format that is slightly more generous (that is, yields a slightly greater width) than the formula for calculating the width from WIDTH-CHARS. Some amount of trial and error might be necessary to arrive at the right format or width for the type of data typically displayed in a field. Capital letters, for example, are on average much wider than lowercase letters, so a field that is displayed all in capitals likely needs a greater width than a lowercase or mixed-case field.

The sample code in the Use the FONT-TABLE to make the labels colon-aligned section provides an example of using a built-in system handle called FONT-TABLE to calculate the display width of a specific string in a specific font, which you can also use to assign an appropriate width.

Label handling

You must provide a separate text object as a label for dynamic data representation objects, including fill-ins, combo boxes, editors, radio sets, selection lists, sliders, and text fields. When you drop fill-ins into the AppBuilder’s design window, for example, the AppBuilder is actually generating separate, dynamic label objects so that you see how the label looks at run time, since it is creating dynamic objects at design time to build up the contents of what will become a static frame and static field-level objects when you save it and it generates code for the frame and object definitions. When you create your own dynamic objects, you have to supply the dynamic text label yourself.

If you want a side label for a fill-in field, or one of the other dynamic data representation object types, you must create a separate text object and then assign its handle to the SIDE-LABEL-HANDLE attribute of the object it is a label for. For any other type of label, such as vertical columns, you must create and manage the text object completely separately. You must also position text objects used as labels explicitly, even for side labels. the AVM assigns no positioning information for dynamic side labels, as it does for button or toggle box labels. The SIDE-LABEL-HANDLE attribute on the fill-in does not actually provide any automatic services such as moving the label together with the field. It is simply a useful way to help you navigate between the field object and its label object when you need to.

The example code described in Add dynamic fields to the test window shows you how to define side labels for dynamic fill-ins.

Data handling

Unlike static data representation objects, dynamic objects have no field or variable implicitly associated with them. You must explicitly assign data between an object’s SCREEN-VALUE attribute and the field or variable you use for data storage. This allows you to use a single object to represent multiple fields or variables at different times, if you wish, limited only by the object and data type.

Data typing

Some dynamic objects support entry and display data types other than CHARACTER. In particular, fill-ins and combo boxes support the full range of ABL entry and display data types. It is important to understand that, for dynamic objects, this support is for entry validation and display formatting purposes only. The SCREEN-VALUE attribute always holds the data in character format, no matter what the object’s data type. You must make all necessary data type conversions using the appropriate functions (STRING, INTEGER, DECIMAL, etc.) when assigning data between the object’s SCREEN-VALUE and the field or variable you use for data storage.