The first statement opens that Customer query and sets you up to retrieve and display each of the Customer records in turn. Now look at the next statement:
GET FIRST CustQuery.

This statement retrieves the first Customer record using the query CustQuery.

Moving on, you see a DISPLAY statement, which should be familiar to you. It has an IF-THEN construct in front of it that you have not seen before, but like most ABL statements, it is self-explanatory. If the query turns out to be empty, or if you reached the end of it, then you do not want to try to display anything. The phrase IF AVAILABLE Customer checks for that:
  IF AVAILABLE Customer THEN 
    DISPLAY Customer.Name Customer.CustNum Customer.Address Customer.City 
          Customer.State 
      WITH FRAME CustQuery IN WINDOW CustWin.

Because a field name might occur in more than one table used in the procedure, the AppBuilder puts the table name in front of each field name, as in Customer.CustNum. This is a good practice for you to follow in the code you write unless your field names are all guaranteed to be unique.

The end of the DISPLAY statement has a qualifier you did not see in previous sections either, WITH FRAME CustQuery. But you can certainly tell what it does. “Use Basic ABL Constructs,” explains that ABL uses frames to define different display areas, and that each field and block of code is associated with a frame. If you do not name the frames yourself, you get default frames. If you need to, you can give each frame a name and specify that frame in a DISPLAY statement. Then the AVM knows exactly where each displayed field or other object should go. You renamed your window’s default frame CustQuery earlier, and here you see that name being used. And remember the AppBuilder uses the same name for the frame’s default query.

The second qualifier is understandable, too. If your procedure happened to define more than one window, then you would have to tell it which frames go in which window. Here the code makes that explicit, by appending the phrase IN WINDOW CustWin.

So apart from these qualifiers this statement should look familiar. Now look at the next statement:
  ENABLE Customer.Name Customer.CustNum Customer.Address Customer.City 
         Customer.State OrderBrowse 
      WITH FRAME CustQuery IN WINDOW CustWin.

Not surprisingly, this statement enables each of the fields for data entry, so that you could make changes to a record and then save it. Also it enables the browse control itself so that you can scroll it up and down. At this time, you will not actually add a Save button to this window to let you save changes (you do that in section, “Update Your Database and Write Triggers”).

Next is another preprocessor value:
  {&OPEN-BROWSERS-IN-QUERY-CustQuery}

If you do a Code Preview again, you can see that this value represents the statement OPEN QUERY OrderBrowse FOR EACH Order OF Customer NO-LOCK INDEXED-REPOSITION. You will get to details like NO-LOCK versus SHARE-LOCK and what INDEXED-REPOSITION means in section, “Use the Browse Object.” Otherwise, you should recognize this as the query you built in the Query Builder when you dropped the browse control onto the window.

The final executable statement is:
  VIEW CustWin.

This statement tells the AVM at runtime to make the window visible.

And finally, as you learned in “Run ABL Procedures”, every internal procedure must end with an END PROCEDURE statement:
END PROCEDURE.

This is all the code that is needed to make all the things happen that you saw when you ran the window. It opens two different queries representing a parent-child relationship between Customers and Orders. It displays and then enables the Customer fields and the Order browse. And it views the window itself. All this happens in about ten lines of ABL code. And you did not have to write any of it yourself.