GUI ScreenIO for Windows

 ScreenIO.com


General Programming Model

In a real application, you will typically display your panel and process the events it returns in a loop until you received an event indicating the user is finished with the panel. Then you fall through the loop and go on to something else, or close your main window and STOP RUN.

 IDENTIFICATION DIVISION.
 PROGRAM-ID. TESTPAN.
 ENVIRONMENT DIVISION.
 CONFIGURATION SECTION.
 SOURCE-COMPUTER. IBM-PC.
 OBJECT-COMPUTER. IBM-PC.
 DATA DIVISION.
 WORKING-STORAGE SECTION.
* ------------------------: Main and the test panel copybooks:
     COPY mymain.
     COPY panel.

 PROCEDURE DIVISION.
* ------------------------: Initialize; create the main window.
     PERFORM DISPLAY-MAIN.
* ------------------------: Display the panel and process events
*                         : until we get a CLOSE event.

     PERFORM WITH TEST AFTER
         UNTIL panel-EVENT-CLOSE-WINDOW
            OR panel-EVENT-CLOSE-AND-STOP

       CALL 'GS' USING panel-1
                       panel-2
                       panel-3
                       panel-4

       EVALUATE TRUE

         WHEN panel-BUTTON-OK
           PERFORM OK-ROUTINE

         WHEN panel-BUTTON-CANCEL
           PERFORM CANCEL-ROUTINE

         WHEN OTHER
           CONTINUE

       END-EVALUATE

     END-PERFORM.

* ------------------------: Close the main window and quit.
     SET mymain-DO-CLOSE TO TRUE.
     PERFORM DISPLAY-MAIN.
     STOP RUN.

* ------------------------: Performed routines.
 DISPLAY-MAIN.
     CALL 'GS' USING mymain-1
                     mymain-2
                     mymain-3
                     mymain-4.

Notice, in the example above, how clean the basic program logic is. The data editing, file updating, and error handling code resides outside of your panel display loop. This makes it much easier to follow what's going on.

Also note that this routine is fail-soft.  Events that you explicitly test for are explicitly handled, and all other conditions are ignored via the WHEN OTHER clause. 

Events

An event is something that caused GUI ScreenIO to return to your program.  Events are usually something the user did; selected a menu item, pressed a button, clicked the X box in the right-hand end of the title bar.  There are other events, but the main point is, when GUI ScreenIO returns to your program, it tells you why - and your program would usually do something based on that event.

The event that caused GS to return is passed back in the panel copybook field panel-EVENT-ID, but you do not (and should not) test that field for specific values.  Instead, you test the 88-level items generated by the panel editor. 

All of the possible events that could be returned to your program are generated into your copybook.  Everything you need to consider is there as an 88-level beneath panel-EVENT-ID.

Suggestion: Use EVALUATE to handle conditions

We prefer to use EVALUATE for handling conditions; it's far easier to read and maintain than IF-ELSE-END-IF logic, particularly if you have many potential events you need to handle.  

Always use the 88 names for Events

Even if you prefer IF-END-IF coding ALWAYS test the 88 names, never check for specific values in panel-EVENT-ID.  Values may change upon subsequent edits of the panels, but 88 names will remain constant unless you specifically change them.  

Choose Menu names and Pushbutton names that are descriptive when setting up your panel.  Your program will be easier to read and maintain.


© 2000-2019 Norcom, all rights reserved 

TOC

Send feedback to Norcom