Benefits and Restrictions

The main benefits of using the Character-to-GUI Wizard are the following:

• The conversion process is faster than manual techniques.
• The resulting screens are placed in AcuBench, ready to use the powerful facilities of the Screen Designer to modernize the screen further. This also provides a nice starting point for bringing the entire application into AcuBench.
• Because the graphical interface is derived from the character one, it retains the efficiencies that have been built into the character interface, and the application’s user base will find the interface familiar and comfortable.
• The resulting program is an ACUCOBOL-GT program. This program can be easier to understand and maintain than those produced via some other conversion techniques that may involve rewriting the screens in another programming language or using an external tool.
• By focusing the tasks to accomplish, the wizard can make the programmer more productive. Replacing an application’s user interface with a graphical one is a daunting task with many decisions to be made. Using the wizard, the task is more concrete: integrating a screen into a program.
• If you need to retain the character-based interface, the wizard’s output works well with ACUCOBOL-GT’s dual-interface features. This makes it easy for a single application to contain both a character and a graphical user interface.
• The wizard creates screens that refer to the original data items used to build the character screen. This makes integration of the graphical screen into the program easier.

The Character-to-GUI Wizard has some important limitations that you should also consider:

• The wizard is available under Windows only.
• Because it mimics the character interface, the resulting graphical user interface makes use of only labels and entry fields. The programmer can add more graphical elements right away or over time as needed, but they are not included as part of the initial conversion.
• The wizard only handles screen labels and entry fields. More advanced elements of a character application are not recognized by the wizard. These include menu bars, pop-up windows, and line drawing characters.
• The wizard uses some source code analysis, some runtime analysis, and some heuristics to decide what on the character screen should be labels and what should be entry fields. While these are usually correct, in some cases the wizard could make the wrong choice. The wizard contains a method for correcting this when it occurs.
• Spacing issues arise when you convert from a fixed-pitch font in the character application to a variable-pitch font in the graphical application. In addition, the boxes around the graphical entry fields occupy screen space that is not present in the character application. As a result, screen elements do not always fit correctly after the conversion. The wizard uses a general-purpose placement algorithm that works well for most screens, but does not ensure that screen fields always fit or look right. You may have to occasionally move or resize a screen field after the screen has been imported into the Screen Designer. You can choose to minimize this effect by using a fixed-pitch screen font and/or using unboxed entry fields. The wizard supports both of these options.
• Screens constructed via techniques other than using ACUCOBOL-GT syntax cannot be converted or convert poorly. This also applies to screens constructed by embedding terminal control codes directly in the displayed data by the application. The wizard is not aware of the effects of the terminal control codes and treats them as data instead. The resulting screens are generally not useful.
• The programmer is responsible for integrating the output of the wizard (a Screen section item) back into the program. The wizard tries to simplify this task by referring to the original data items and screen names as appropriate. However, in some cases, the data item may not be correct or even legal. For example, if you construct some portion of a screen out of data contained in a table, the resulting Screen section item could contain several identical table references for logically distinct items. (This would happen if the screen were constructed by processing the table in a loop.)
• Screens that are not treated by the application as a series of fields do not convert well. For example, if you have a word processor application where the body of the screen is managed by single-character ACCEPT/DISPLAY statements, the wizard tries to treat each character as a distinct field. The results are not useful.
• The wizard does not handle screens whose set of fields change based on other actions. Essentially, when you import you get an image of the screen as it is at that time. If the screen is dynamic, then that image expresses only one form of the screen.