GUI ScreenIO for Windows

ScreenIO.com

Events - What Caused GUI ScreenIO to Return

Whenever GUI ScreenIO returns to your program, it tells you why in the field panel-EVENT-ID.  

What causes events?

Events can be triggered by a number of happenings; 

• An item was selected from a menu, including a context menu
• The user entered, changed, or left a hot field
• The user clicked the "X" box in the right side of the title bar to close a window
• The user selected an item from the System menu (the one triggered by clicking the icon in the left end of the title bar)
• Some controls may return events; for example, a listview control will ask for more data if the user scrolls beyond what GUI ScreenIO has in its cache
• If you are displaying panels in multiple working-sets, GUI ScreenIO returns an event informing you of when the user switches from one working-set to another
• You displayed a messagebox and the user pressed one of the buttons in it

Event names

All possible events that can occur are defined as 88-level items in your panel copybook.  There are several standard events that are assigned names by the GUI ScreenIO panel editor.

You assign your own names to events that you define (such as menu selections, or pushbutton events).  This makes your code very readable.

Important Note: 

You should Never! Never! Never! refer directly to panel-EVENT-ID when you evaluate events, because the numbers assigned to events by the panel editor are arbitrary and may change. 

Always use the 88-level names to evaluate events.  This also makes your program much more readable, particularly because YOU assign the names to events that you define.

Why does GUI ScreenIO use 88-level items for events?

We designed GUI ScreenIO to use 88-level items for this kind of thing so that all of the information you needed to handle a panel in your program is contained in the panel copybook.  All you need to do is to refer to the 88-level names.

All of the possible values that could be returned are defined beneath this field in 88-level items.  This makes it very easy to interpret them, since it's all right in front of you.  

Here's an example from a panel copybook.  The names assigned to events are always prefaced by the panel name so that they are unique; this eliminates problems if a program contains more than one panel.

In this example, the first five event IDs are standard events which are present on all panels.  panel-MY-PUSHBUTTON is the event that will be returned if the user triggers the panel object that is assigned this event.  In this case, it's assigned to a pushbutton.

Standard Events and Programming Actions

Because GS will only return events that you explicitly define when you create your panel (plus a couple of standard events common to all panels), you don't have to worry too much about the type of events it will return. You already know the possibilities.

Suggestion: Use EVALUATE to handle events

We prefer to use EVALUATE for handling conditions; it's very clean and easy to read and maintain. 

This code sample shows how we handle events using EVALUATE.  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.