Event Driven Programming

Description

A graphical interface typically offers a variety of controls that the user may operate at random using the keyboard and/or the pointing device. Any of these user choices can potentially generate events, some of which require the application to deliver an appropriate response. Since the user may initiate an event from any active control on the screen, the software is said to be event driven.

Character-based applications have used event-driven methods for some time. Applications that incorporate pre-assigned function keys or menu-driven interfaces are good examples.

The following table contains an alphabetical list of the events that can be passed and the corresponding event mask flag bits:

Event to Report

Event Mask Bit

Activate or deactivate application or window

$40000000$

Check or uncheck of check box or radio button

$02000000$

Click or double click on list item

$01000000$

Close box operated

None – always sent

Edit or list edit modified

$00400000$

Edit, list edit, or text edit focus change

$00800000$

Key pressed

$00000400$

Menu selection made

None – always sent

Mouse button double click

$00000200$

Mouse wheel scroll

$00000020$

Mouse button down

$00000040$

Mouse button up

$00000080$

Mouse moved

$00000100$

Push button operated

None – always sent

Scroll bar position changed

$00100000$

Tool button operated

None – always sent

Window resized

$00000008$

Window focus change

$00000004$

System color change

$80000000$

Notice that four basic events are always sent. It is the developer's responsibility to specify in the event masks which additional, optional event codes will be passed. For example, if the window will contain radio buttons to which the program must respond, then the event mask should enable the reporting of radio button selection.

Visual PRO/5 allows the programmer to disable and enable the windows/dialogs for each application, or to evaluate the reported events by context. Each application may itself contain several window and/or dialogs. All events from all the windows are reported through a single queue for ease of programming.

It is the developer's responsibility to scan the event queue, identify the events being reported, and initiate the appropriate responses. Typically, a looping structure such as SWITCH is used to scan the SYSGUI device for events. A selection structure is then used to determine what the events were and what responses are appropriate from the application.

Recognizing Events

The SYSGUI device reports all events through a single event queue. Each event is returned as a fixed-length string in a standard format. To minimize the risk of generating preventable run-time errors, string templates are recommended for retrieving event data. Using a string template for retrieving event data ensures that the application program will always have a correct reference to the control that passed the most recently received event. A template for the event structure may be obtained with the new TMPL(channel) function for retrieving template data on open channels. For example:

OPEN(channel)"X0"
DIM EVENT$:TMPL(channel)
READ RECORD (channel,siz=len(EVENT$)) EVENT$

The format for an event returned by TMPL(sysgui_channel) is:

Template Field

Meaning

context

Event Context ID

code

Code for the type of event

id

ID of the control sending the event

flags

Flags – interpretation varies with type of control

x

X location or dimension

y

Y location or dimension

Each Visual PRO/5 window is created in a context that serves as the frame of reference for objects and events associated with that window. When taken with the context field, the id field uniquely identifies the control that us associated with the event.

A program recognizes events by the values of the code field in the event messages. However, this is often insufficient information to determine the application's response. Additional information about an event is passed in the flags and x and y parameters.

There are four mandatory events that are always passed through to the queue by the SYSGUI device when they occur. The reporting of all other events is optional, based on the event mask of the window in which the event occurs.