Selecting the best approach to supporting both graphical and character systems is very important and well worth the time invested. In general terms, there are three possible approaches to this problem. You can use ACUCOBOL-GT with any of these approaches. These approaches can be summarized as follows:
Dual interface, dual code
This approach uses separate programs for graphical and character systems.
Single interface, single code
This approach uses one program with a single user interface that runs under
both graphical and character systems.
Dual interface, single code
This approach uses one program that includes two user interface
implementations, one for graphical systems and one for character systems.
Each of these approaches has advantages and difficulties. The following sections consider the major issues.
1.6.2.1 Dual interface, dual code
This approach is in many ways the most obvious and straightforward. It is also the approach used most often by other programming systems: simply write different programs for the graphical and character systems. The big advantage of this approach is that you can customize the code for the characteristics of the host system as much as you want. Additionally, you incur no overhead for having to include code that is not used for a particular system. Finally, when you are programming you don't have to think about two systems at the same time. Development time for any one system is shortened and testing is easier. These are all significant advantages.
Unfortunately, there are also many significant disadvantages. You have to write two programs instead of one. And, you must maintain two programs. Because there are two programs, you are likely to encounter twice as many bugs. Also, the time required to develop the set of programs is most likely greater than required by the other approaches.
Here are some cases where this approach offers significant advantages:
1. If you are in the process of retiring or freezing a character-based application, then you can simply use that application as the starting point for its graphical incarnation and leave the character version in its original form in an archive for future maintenance. In this scenario, you do not expect to do much more work on the character version, so spending a lot of effort in maintaining a single piece of source code is probably not worth what you gain.
2. If you intend to have sizable functional differences between a character-based application and its graphical sibling, then it might not make sense to try to have a single program cover both cases. In this case, you really do have two different programs, with some overlap in their functionality. The overlapping portions could be maintained as a separate library of source that is shared by both systems.
In general, if you view the character-based application as having a limited future, then this approach generally makes the most sense. The other two approaches are more attractive if you plan on maintaining and enhancing the character-based application in the future.
1.6.2.2 Single interface, single code
This approach relies on ACUCOBOL-GT's ability to run the same program on any machine. With this approach, you write a single program that has a single user interface that runs on all machines. The big advantage of this approach is that you need to write and maintain only one program. The disadvantages are that you will have to work harder to get a program that looks good on all systems, and you are limited to only those features that are available on both graphical and character-based systems. Generally, this means developing a simpler user interface for the graphical system than you might otherwise choose. If you presently have a character-based user interface and do not plan to add graphical controls, then this approach is straightforward to pursue and is the obvious choice.
The biggest challenge to this approach is developing code that works well under both systems. This generally means a lot of back-and-forth development under Windows and a character-based system to ensure that the results look good and work well. Fortunately, you can use the DOS box under Windows to do the initial character-based testing, so you need only one development platform. Note that you must have a DOS runtime in addition to your Windows runtime.
This approach generally accommodates graphical single-line labels and entry fields. Getting labels and entry fields to look right on both types of systems is fairly easy. Incorporating other graphical elements tends to be harder and should be done sparingly.
ACUCOBOL-GT does not yet support all control types on character-based systems. In particular, bars, scroll bars, bitmaps, and tabs are not supported, so you need to avoid these when using this approach. Support for these controls may be included in a future version.
1.6.2.3 Dual interface, single code
With this approach, you write a single program that includes two user interfaces: one for character systems and one for graphical systems. The two user interfaces gather the same data, but in a fashion that is customized for the host system. After the data is collected, the remainder of the program is the same between the two systems.
This approach combines some of the advantages and disadvantages of the other two approaches. On the positive side, there is only one set of source to maintain. There is less programming than the dual code approach, but you aren't forced into the simplified user interface typically required by the single interface approach. You can customize the user interface to take advantage of features found on a graphical system without making the character-based version unmanageable.
The biggest disadvantage is that you must write two user interfaces. While this is less work than writing two separate programs, it is still a significant amount of work. In addition, you must test the user interface code more thoroughly than with the single interface approach, because only half of the interface code is exercised on any one type of system.
1.6.2.4 Selecting the right approach
Each of these approaches has its merits. One thing to remember is that you can mix the approaches. Mixing approaches can be quite useful in a large project. Imagine a standard accounting package. In it, you might use the dual code method to handle the main menu of the package. For example, the graphical version might display a nice graphic and use the system's menu bar to initiate the subsidiary applications. The character version might instead display the menu as the main contents of the opening screen since it can't show a graphical image. Parts of the application that perform maintenance of minor files (such as shipping codes and user passwords) or entry of report parameters, might use the single interface approach because the screens are simple. Finally the key transaction entry screens (such as an order entry screen) might use the dual interface, single code approach to ensure that the screens work well for the respective systems while also ensuring that the entered data is handled the same way by both systems.
You can even mix approaches inside a single program, or even a single screen. You might have most of a screen use the single interface approach, while a small portion of it is customized by using the dual interface technique.
You do not need any special tools to use the dual interface, dual code approach (although a good source-code control system always helps). For the two single code approaches, ACUCOBOL-GT has special features to simplify use of the single interface and dual interface methods. The next section discusses these features and when you might use them.