Field Property-related Issues

The most common issues are those related to field properties. Color and transparency issues are hard to detect and quantify comprehensively by manual means, and realistically they cannot be fixed manually, because there are too many occurrences. But they can be corrected simply using an automated tool.

This developer issue is widespread and will need to be corrected in most applications. It typically manifests as frames having areas with the wrong color. Actian provides an automated PropertyChanger utility to assist you in correcting this problem. To request the PropertyChanger tool, contact Actian Support at http://supportservices.actian.com/support-services/support#contacts.

For more information about this issue and its resolution, see Incorrect FP_CLEAR Field Setting and Upgrading Applications with the PropertyChanger Utility.

If you are using your own color definition file for OpenROAD and plan to continue to do so, you may skip this section.

ISSUE: OpenROAD changed the color definitions it uses between version 3.5 and 4.0. These definitions have not changed since.

In applications developed initially in OpenROAD 3.5, CC_PALE_GRAY and CC_LIGHT_GRAY were identical, and many fields were set to one or other indiscriminately.

The same thing happened to CC_SYS_BTNFACE when Microsoft’s definition of their button gray was switched from rgb(192,192,192) in Windows NT to rgb(212,208,200) for Windows XP.

When you convert to the latest release of OpenROAD, the grays will be unacceptably different and will need to be reconciled. In many cases, the other colors will differ from those in the OpenROAD 3.5 application potentially to such an extent that they also will need to be changed.

RESOLUTION: If you decide to reset the non-gray colors, the most effective and low-cost route is to define your own color table (see the following procedure).

We recommend that you reset the grays. Since no adjustment of the color table will deal with the change to CC_SYS_BTNFACE, and the distinction between CC_PALE_GRAY and CC_LIGHT_GRAY in existing applications is a developer issue and not an intentional implementation, we recommend that you use the PropertyChanger tool mentioned previously to correct this (see Incorrect Field Colors). For more information, see Upgrading Applications with the PropertyChanger Utility.

1. Make a copy of the apped.ctb file in your OpenROAD 3.5 installation (\ingres\files\apped.ctb). Name it something like apped_latest.ctb.

3. In a command window on your OpenROAD 5.1 installation (that is, with the II_SYSTEM appropriate to that installation), issue the following command to point the OpenROAD color handler to your new file:

In the unlikely case that they are not, you will need to adjust the settings in the CTB file until the colors are acceptable.

5. Change your deployment specifications to ensure that %II_SYSTEM%\files will contain apped_latest.ctb, and II_COLORTABLE will point to apped_latest.ctb in each upgraded client installation.

See Incorrect Field Colors.

Note: If you are certain that all of your TableFields use OpenROAD’s built-in TableField header or use no TableField header, you may skip this section.

If your application may have some pseudo-headers built within a separate StackField, you will probably need to make corrections.

It is possible that a simple font change will fix this problem in most or all places. Where it does not, you will need to scan the entire runtime application manually for table header alignment discrepancies, and correct them individually.

ISSUE: TableFields in OpenROAD 3.5, although powerful, had limited column header support compared to rival products. A number of application developments replaced the native OpenROAD TableField header by a more visually acceptable StackField-based pseudo-header, whose contents were manually adjusted to align with the TableField columns. In many cases, the application code included specific references to these pseudo-header fields.

Font-mapping changes starting in OpenROAD 4.0 and beyond caused virtually all such pseudo-headers to become misaligned unacceptably, and application changes became necessary.

RESOLUTION: Redefining the TF_SYSTEM font in appedtt.ff (or the font file referenced by II_FONT_FILE, if defined), may resolve this problem. You can reset it to the font specified in the OpenROAD 3.5 installation (not recommended), or you can switch it to Arial. This solution will change all fields that currently use TF_SYSTEM; be sure that the result is acceptable.

1. Make a copy of the appedtt.ff file (or the font file referenced by II_FONT_FILE, if defined) in your OpenROAD 3.5 installation (\ingres\files\appedtt.ff). Name it something like appedtt_latest.ff.

2. Edit this file and replace the font name used in the six definition lines supplied for TF_SYSTEM with the name “arial”. Save and close the file.

3. In a command window on your OpenROAD 5.1 installation (that is, with the II_SYSTEM appropriate to that installation), issue the following command so that OpenROAD will use your new file:

4. Run your application from OpenROAD Workbench. Check that the TableField pseudo-headers are correctly aligned and that the effect on other fields remains acceptable. If not, re-edit the appedtt_latest.ff file and the corresponding file in your OpenROAD 3.5 installation. Copy the six definition lines supplied for TF_SYSTEM from the 3.5 file, and use them to replace the corresponding six lines in the 5.1 file.

5. Re-run your application from Workbench. Check that the TableField pseudo-headers are correctly aligned and that the effect on other fields remains acceptable.

If redefining the TF_SYSTEM font does not resolve this problem, you will need to adjust the field widths in the pseudo-headers to realign the fields.

Identifying and manually adjusting pseudo-headers is painstaking and slow. Using an adapted crawler tool is undoubtedly more cost-effective, but it will need to be adapted and tested to match the pseudo-header implementation. In this situation we recommend that you engage Actian Services to assist with the conversion (http://supportservices.actian.com/support-services/support#contacts).