It's an aesthetic thing. When you click on a grid DataWindow label and change an attribute, it acquires what are formally termed UGBs - Ugly Grid Borders. They appear between the labels in the grid header. The vertical lines are thin or thick. Inconsistency! Thick borders! Yuck! Figure 1 illustrates the problem.

There are thick borders between the Nickname and Last Name labels and between the Company and Nickname columns; there are thin borders between the Company and Nickname labels and between the Nickname and Last Name columns.

Figure 2 shows the same DataWindow with the UGBs fixed.

All the borders are thin in Figure 2, which looks a lot better.

The UGB problem is characteristic of 3D objects on grids. The detail columns in the figures are 3D lowered. You don't have to worry about UGBs if all your DWO objects are flat.

With PB6 and earlier releases it was easy to fix the UGBs manually: select the left-most column label, hold down the shift key and press the right arrow key to select all the labels, then right-click that left-most label and select Bring to Front from the popup menu.

With PB7 (and later) that trick stopped working: you can't fix all the labels in one operation. With recent versions of PowerBuilder, you have to fix one label at a time, going left-to-right: right-click the label, Bring to Front, right-click the next label, Bring to Front, etc., for every label on the grid; ditto for columns. It's a pain.

This article presents a programmatic solution to UGBs. It turns out that the problem is how lines are ordered in the DWO syntax. The code presented in this article fixes the DWO syntax, banishing those embarrassing UGBs. Once you're set up, you can fix all the UGBs in your application in a few minutes. It becomes part of the build process, so your programmers can ignore the problem and your users are forever spared UGBs. A utility for fixing UGBs is provided.

Looking at the Syntax
In DWO syntax, labels correspond to text objects. If you look at the exported DataWindow syntax, before and after fixing the UGBs, you'll find that the order of the text object declarations has been changed. The first part of the text object syntax line looks like:

text(band=header S x="9" y="8"S

It turns out that the critical part of the syntax is the x attribute, x="9" in the line above. When a grid has UGBs, the text lines are not in x-attribute order. The following shows how the text object declarations are ordered when the UGBs have been eliminated:

text(band=header S x="9" y="8"S
text(band=header S x="338" y="8" S
text(band=header S x="3470" y="8" S

The x attributes are 9, 338, and 3470 - monotonic ascending order.

Here's what I infer: PB instantiates DWO objects, processing the DWO syntax in top-to-bottom order, and the UGBs appear when the objects' order of instantiation is not uniformly left-to-right.

The solution is to reorder the 3D-object syntax lines according to their x attribute.

The Code
The main function is f_fix_ugly_grid_borders(). It takes a DataWindow control (DWC) upon which the target DataWindow object (DWO) appears. Here is a high-level description of f_fix_ugly_grid_border():

• Figure 1
• Figure 2
• Source Code (zip file)