One of the most important things that you can do when implementing a user interface that includes graphical controls is establish the program's main application window correctly. By default, ACUCOBOL-GT will construct a main application window for you. However, this window is designed to run traditional, text-based COBOL programs and not programs with graphical controls. The run-time does this so that it can run older ACUCOBOL programs unchanged. If you plan to use graphical controls, it is very important that you do not use the default window. Instead you should explicitly create your window. There are two reasons why this is so important:
Format 12 of the DISPLAY verb is used to create the main application window. See DISPLAY Statement for the rules that govern its use. See Coordinates for a more detailed discussion of coordinate space issues. Here are a few suggestions for handling the most common situations for graphical programs:
DISPLAY STANDARD GRAPHICAL WINDOW, CELL SIZE = ENTRY-FIELD FONT, SEPARATE
77 LARGE-FONT USAGE HANDLE OF FONT. ACCEPT LARGE-FONT FROM STANDARD OBJECT "LARGE-FONT" DISPLAY STANDARD GRAPHICAL WINDOW CONTROL FONT IS LARGE-FONT CELL SIZE = ENTRY-FIELD FONT, SEPARATE
There are many other options you can add to the DISPLAY STANDARD WINDOW statement, including the ability to set the window's size. The preceding suggestions just cover the basics of establishing the measuring font.
If you follow suggestion number two above, then you should find that you can place labels and entry fields on whole line numbers and have them show up nicely spaced under both character and graphical systems. Because the line height is determined by the height of a boxed entry field, each line is exactly big enough to hold one entire entry field. This solves the problem where entry fields are 50% taller on graphical systems than they are on character systems.
An alternative solution is to avoid using boxes with entry fields on graphical systems. You can do this very easily by using the FIELDS_UNBOXED configuration option. However, while this solution is very easy, it has two problems. One is that the results look a little out of place under Windows, where boxed fields are the norm. The other problem is that unboxed entry fields are used so infrequently under Windows that the underlying Windows code is not well exercised. Occasionally you will see slightly odd behavior with unboxed entry fields under Windows (for example, leaving a stray pixel turned on when it should be erased during editing).