The next part of the procedure consists of mostly internal comments for the AppBuilder’s benefit, but there is one executable statement in it, and you look at it to learn one or two more things about dynamic objects:

IF SESSION:DISPLAY-TYPE = "GUI":U AND VALID-HANDLE(CustWin)
THEN CustWin:HIDDEN = no.

This statement means: “If the session’s Display Type is GUI and the window handle named CustWin is valid, then set the window’s HIDDEN attribute to no.”

The VALID-HANDLE built-in function tests to see if the structure the handle points to has been properly associated with an object.

Will the handle be valid? It should be because the procedure created the window that uses it just above this. But in your own procedures, you can use handles long after they are defined. You must always make sure that they point to valid structures before you use them.

This language statement demonstrates that in ABL you can set the attributes of a dynamic object after the CREATE statement by using a reference to the object’s handle, followed by a colon, followed by the attribute name. You can read attributes in the same way, as in:

IF CustWin:HIDDEN = no THEN
.
.
.

Using dynamic objects is a very powerful way to write general-purpose procedures that can handle a whole set of variations on any common pattern in your application, whether it is windows with different titles, sizes, and contents, or browses on different queries with different columns displayed. You learn a lot more about these dynamic language constructs later.