The window is a different kind of object—a dynamic object. You use a CREATE statement rather than a DEFINE statement for it. When you create the object you associate the object with a HANDLE variable that must already be defined. It is for this that the DEFINE VARIABLE CustWin statement you saw earlier was coded. The handle acts as a pointer to a structure that describes the object, but it is different from the structure resulting from a DEFINE statement in that the structure is only built up at run time, as the program is executing. This allows you to set some or all of the object’s attributes based on program conditions. So, in effect, the CREATE statement creates an empty shell to be filled in with the object’s description, and the handle points to that shell. Here is the CREATE statement for your window:

IF SESSION:DISPLAY-TYPE = "GUI":U THEN
  CREATE WINDOW CustWin ASSIGN
         HIDDEN             = YES
         TITLE              = "Customers and Orders"
         HEIGHT             = 20.81
         WIDTH              = 80
         MAX-HEIGHT         = 20.81
         MAX-WIDTH          = 80
         VIRTUAL-HEIGHT     = 20.81
         VIRTUAL-WIDTH      = 80
         RESIZE             = yes
         SCROLL-BARS        = no
         STATUS-AREA        = no
         BGCOLOR            = ?
         FGCOLOR            = ?
         KEEP-FRAME-Z-ORDER = yes
         THREE-D            = yes
         MESSAGE-AREA       = no
         SENSITIVE          = yes.
ELSE {&WINDOW-NAME} = CURRENT-WINDOW.

Around the CREATE WINDOW... statement is an IF-THEN-ELSE statement. This rather cryptic-looking sequence effectively says: “If you are running in the GUI environment, as opposed to on a character device, then create the new window CustWin, which will appear as its own identifiable display space on the desktop. Otherwise use the default (and only) window that is always there for character environments.”

This DISPLAY-TYPE test is the answer to a question that might have popped into your head:

Why has the AppBuilder made the window dynamic when everything else is static?

There is no DEFINE WINDOW statement in ABL, only the CREATE WINDOW statement. And this, in turn, is because ABL procedures are designed to be compilable for different environments largely without change, including graphical and character environments. There is only one “window” in a character environment, and that is the entire display device. So your code can never ask a character device to create another window. Thus, to have the same code compile and run in both GUI and character, creating the window in the GUI environment must be conditional. And that is exactly what dynamic objects are for: to let your procedures decide at run time what objects to create and what attributes to give them.

To set a dynamic object’s attributes, you normally reference the handle in later program statements. However, in this case the CREATE WINDOW statement itself has an ASSIGN phrase that sets all the window’s attributes to their proper initial values. In principle, you can define a dynamic object by associating it with a handle, and then set and reset its attributes as needed.