The relationship between format and width that the example highlights might seem confusing. Keep these basic guidelines in mind:

  • The FORMAT is the maximum number of characters the user is allowed to type into the field at run time.
  • The WIDTH-CHARS (or WIDTH-PIXELS if you measure your objects that way) is the actual screen real estate allotted to the object, whether it is for display or for data entry purposes. You can use the FONT-TABLE methods to calculate a precise width for a single displayed value, but you must estimate an appropriate width for a field that can be used to display many values, for example as you navigate through many records in a table.
  • If you assign a format but not a width, the AVM estimates a width based on the format. This normally is slightly greater that the width as based on WIDTH-CHARS, because the AVM tries to provide additional space to prevent truncation of, in particular, short values with wide characters (such as a two-character capitalized state abbreviation, for instance). Therefore, you must assign an explicit width (using WIDTH-CHARS or WIDTH-PIXELS) if you want to make sure the display space is not bigger than it needs to be, for example to prevent overwriting an object displayed next to the object you are sizing.
  • If, on the other hand, you assign a width but not a format, the AVM uses a default display format for the data type. For a CHARACTER field, for example, this is "X(8)". This is not likely to be appropriate, so you almost always need to assign a format.
  • If the format is larger than the display width for a CHARACTER fill-in field that is enabled for input, the user can type as many characters as the format allows. If the display space runs out, the fill-in automatically scrolls to allow the user to enter more data. This is very often a desirable user interface design, which displays a reasonable number of characters for a field but allows the user to type more when necessary (and have it all stored in the underlying field).
  • If the format for a CHARACTER fill-in is smaller than the display width and the user tries to type more characters than the format allows, the AVM prevents this. The user gets only a warning bell as he continues to type, even though there is still visible display space available that was allocated by the width attribute. This is a very bad user interface design, which leads to the following basic guiding principle.
  • When in doubt, make the format generously large and the width appropriate for the display. Limit the format size for enabled fields only when it is important to limit the number of characters stored in the underlying variable or database field. Remember that all ABL CHARACTER variables and fields are inherently variable width, so the format of a database field does not allocate a fixed storage size, but only what a particular field value uses for each record.