This section describes how to use selected features of ACUCOBOL-GT to solve common problems encountered when developing programs to run on both character and graphical systems.
1.6.3.1 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 runtime 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.
Since the runtime'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 Book 3, section 6.6 for the rules that govern its use. See Chapter 4, section 4.5 of this book 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
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).
3. 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).
1.6.3.2 Tips for building single-interface programs
Here are some ideas for simplifying the task of supporting a single user interface on both character and graphical systems:
1. If you plan to use the bar, scroll bar, tab, or bitmap controls for your graphical programs, make sure you program alternatives for the character-based systems (in other words, build a dual-interface program for these elements).
2. Make sure you establish a sensible cell size as described in the previous section. This is the only way you can hope to have a single set of coordinates describe screens that look good under both character and graphical systems.
3. Provide plenty of space between elements on the same line. Items that appear to be nicely separated on a graphical system may well overlap under a character-based system. This occurs because the labels and control titles are narrower on a graphical system due to the nature of the proportional font used.
4. If you use frames, design them on the graphical system. The runtime automatically grows frames as needed on character-based systems to surround the contained controls.
5. In general, try to keep the screens simple. The more complex they are, the harder it is to achieve a nice look under both types of systems.
6. Try to use a single size font under the graphical system. The character system has only one size, so you can get more uniform results if you do the same under graphical systems.
7. For cases where you cannot get a nice look under both systems using a single set of coordinates, use the CLINE, CCOL, CSIZE and CLINES options. These allow you to specify alternate coordinates and dimensions for character-based systems. This lets you customize the placement of screen elements for both graphical and character systems, giving you finer control. For more information about these phrases, see Chapter 3, section 3.6.
1.6.3.3 Tips for building dual-interface programs
The key to building dual-interface programs is being able to determine which kind of system you are using. ACUCOBOL-GT provides two methods to accomplish this:
1. You can determine whether you are running under a character or graphical system by using the ACCEPT FROM TERMINAL-INFO verb. The HAS-GRAPHICAL-INTERFACE field is "true" when the host system is graphical, otherwise it is "false". You can also use the WIN$VERSION library routine to get more detailed information about the Windows host operating system (see Book 4, Appendix I).
2. In the Screen Section, you can automate the detection of character and graphical systems with the CHARACTER and GRAPHICAL reserved word labels to indicate entries that apply to only one system (see Chapter 4, section 4.3).
You have a great deal of flexibility in how you implement dual interface programs. On one extreme, you can have completely separate interfaces for character and graphical systems. On the other, you can have a uniform interface with only minor differences between them. Here are some ideas to consider:
1. If you are happy with your existing character interface, you may want to leave it alone and simply develop a new graphical interface. You could either start from scratch, or use your existing character interface as a starting point. If you decide to have completely separate interfaces, then you should start by isolating your character interface into one branch of an IF statement that tests HAS-GRAPHICAL-INTERFACE. You then develop the graphical interface in the other branch. Exactly the best way to do this depends on the structure of your code.
2. If your existing character interface does not use the Screen Section, consider using the Screen Section for the graphical interface. While using the Screen Section is not required, it is easier because it automates all of the mouse handling and transfer of control between screen fields.
3. If you do use the Screen Section for your character interface, you can use the CHARACTER and GRAPHICAL reserved word labels to do customization. You could do this either globally, by creating separate level 01 screen items for each system, or individually on selected fields. Note that you may have two screen items with the same name, as long as one is a CHARACTER item and the other is a GRAPHICAL item. This allows you to have a single set of interface code in the Procedure Division while still coding different screens.
4. Consider employing some of the tips from the single-interface model. The more similar your two interfaces are, the easier they are to maintain.