Progress
Programming
Handbook


Program Execution in an Event-driven Program

The flow of execution in an event-driven program is primarily determined by the system and, to some extent, by the user. Event-driven programs respond to input by repeatedly checking for events. An event is any type of interaction a user or operating system can have with an application. Events can occur as a result of user action or program code, or they can be triggered by the system.

In the event-driven model, virtually all actions supported by the application are available to the user at all times. The user can interact with the program freely, choosing from many simple tasks and combining them in any order to achieve a desired goal. Also, the user can usually change or undo an action easily, without disrupting the current task. Instead of just displaying status messages, event-driven applications display the effects of actions as they occur.

In the event-driven model, the operating system sends information on many kinds of events to the application. The application responds to and takes action on only those events that it has been preprogrammed to recognize and ignores any other events. Figure 2–3 shows this process.

Figure 2–3: The Operating System Interacting with an Event-driven Application

Because it triggers events, the system is said to determine the flow of execution. The programmer sets up a series of triggers to be executed in response to events. Each trigger is a programmed response, a self-contained block of code that performs a specific task. Once these triggers are set up, the system waits for actions that initiate another sequence of events. This sequence of events determines which of the predefined triggers are executed and in what order. The programmer does not generally define the order in which these triggers are executed.

Figure 2–4 shows the flow of execution in a typical event-driven program:

Figure 2–4: Flow of Control in an Event-driven Program

Program execution starts at the top of the program and proceeds sequentially to an input-blocking point where the program waits for events. During program initialization, the program sets up the user interface: it registers definitions for the functional objects of the user interface (buttons, frames, and triggers). Then the program enters a WAIT-FOR state. While a program is in a WAIT-FOR state, the program is said to be blocking for input. In this state, the user interacts with the functional components of the interface to initiate events. When the user performs an action that initiates a specific event, an event handler or trigger code block executes.

The main purpose of the WAIT-FOR condition is to control dismissing the interface. While a program is in this state, the user can interact with user interface objects, based on what their labels indicate about their associated functions, to initiate events. The user initiates an event by performing an action that triggers an event, usually with the keyboard or mouse. When there are no more events to trigger, the user can either cancel the transaction or initiate the event that satisfies the WAIT-FOR condition. After dismissing the interface, program control returns to the interface that called it, if any.

Progress supports user interface triggers that allow users to associate a task (large or small) with an action, such as choosing a button or menu item, or entering a field. In addition, Progress supports the normal control structures required for procedure-driven programming as well as flexible control structures (ON, ENABLE, DISABLE, WAIT-FOR, and PROCESS EVENTS statements) for event-driven programming.

In an event-driven application, complex sequences of actions are not preprogrammed. Only the specific individual actions are preprogrammed. Each of these actions might be associated with an action that takes place in response to a menu item, button, or combination of key presses.

Event-driven programming is rooted in interrupt-driven, real-time operating system technology. With interrupt-driven processing, the operating system can interact with the user and allow the user to access the machine during program execution. Requests to the operating system (interrupts) are acted on immediately. Events, therefore, resemble operating system or real-time interrupts, where real-time refers to the requirement that the software coordinate its activities with the real-world environment, in this case the user.

When you are interrupted while performing a task, you typically stop what you are doing, record where you are, take care of the interruption, and later return to your original task. Interrupt handling in computers provides for a similar process to occur in relation to the execution of a program. When an interrupt signal occurs within a computer system, the computer’s central processing unit:

  1. Stops executing the current program or procedure and saves its context (WAIT-FOR).
  2. Starts executing another program or procedure (trigger).

Thus, when a user initiates an event, it sends an interrupt signal to the operating system. This signal then triggers a real-time response (it applies an event) in the program.


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095