Establishing the Initial Window

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:

1. It gives you an opportunity to account for the height difference between character-based entry fields and graphical entry fields. How to do this is described below.
2. It ensures that your program will look right when run under various Windows machines using different resolutions. If you use the default, you risk having your program look wrong when run under some Windows configurations. The reason for this is that the standard fonts used at higher resolutions are often not the ones supplied by Microsoft. Instead, they come from the video card manufacturer. Sometimes, the relative proportions of the standard fonts are changed from those seen in the Microsoft fonts.
3. Since the run-time's default window uses the FIXED-FONT to measure lines and columns, but your controls usually use some other font (such as the DEFAULT-FONT) to determine their size, a change in proportion between these two fonts causes the screen to change. This can result in overlapping controls and other problems. This is not a bug, but an effect of the changing environment. By establishing your initial window correctly, you can use the same font to position controls as you use to size the controls. Then, regardless of the size of this font, your whole application will scale itself proportionally and look fine.

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:

1. Use DISPLAY STANDARD GRAPHICAL WINDOW. The GRAPHICAL phrase ensures that the default font used for controls is also used to determine lines and columns in the window.
2. If boxed entry fields are going to be a major element of the window, then use the following statement:

   DISPLAY STANDARD GRAPHICAL WINDOW, 
       CELL SIZE = ENTRY-FIELD FONT, SEPARATE

3. You can substitute OVERLAPPED for SEPARATE if you prefer. This statement also works well if vertically stacked push buttons are a major component of the screen (push buttons require about 1.5 lines each, just like boxed entry fields).
4. If you plan to use a font other than DEFAULT-FONT as your primary font, name it as the CONTROL FONT. For example:

   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).