Event-Driven Programming - Essentials of Interactive Computer Graphics - page 15

ming solutions are based on an algorithmic organization of control structures in
the main() function, an event-driven programming solution is based on the spec-
ification of events that cause changes to a defined application state. These are
different paradigms for designing programming solutions. The key here is that,
as programmers of an event-driven program, we have no explicit control over the
algorithmic organization of the events: over which, when, or how often an event
should occur.

Application state. This is
the collection of information
that describes the computa-
tional purpose of the appli-
cation. For example, in the
ball-shooting program, the ap-
plication is defined to create
a HeroBall and simulate the
collection of balls in the ap-
plication window. Thus, these
objects are defined at Label
(A1) in Listing 1.4.

Listing 1.4 shows an event-driven program that implements the left mouse
button operations for our ball-shooting program. We see that during system ini-
tialization (A), the program defines an appropriate application state (A1) and reg-
isters left mouse button (LMB) down/drag/up events (A2). The corresponding
event service routines (D1, D2, and D3) are also defined. At the end of each event
service routine, we redraw all the balls to ensure that the user can see an up-to-
date display at all times. Notice the absence of any control structure organizing
the initialization and service routines. Recall that this is an event-driven program:
the overall control structure is defined in the MainEventLoop() , which is external
to our solution.
Listings 1.5-1.6 show how our program from Listing 1.4 is linked with the
pre-defined MainEventLoop() from the GUI system. The MainEventLoop()
calls the SystemInitialization() function defined in our solution (A). As de-
scribed, after the initialization, our entire program is essentially the three event
service routines (D1, D2, and D3). However, we have no control over the invo-
cation of these routines. Instead, a user performs actions that trigger events that
drive these routines. These routines in turn change the application state. In this
way, an event-driven programming solution is based on specification of events
(LMB events) that cause changes to a defined application state ( AllWorldBalls
and HeroBall ). Since the user command-parsing switch statement (D in List-
ing 1.5) in the MainEventLoop() contains a case and the corresponding default
behavior for every possible user actions, without any added complexity, our solu-
tion honors the non-application-specific actions in the environment (e.g., iconize,
moving of application window).
In the context of event-driven programming, an event can be perceived as
an asynchronous notification that something interesting has happened. The mes-
senger for the notification is the underlying GUI system. The mechanism for
receiving an event is via overriding the corresponding event service routine.
From the above discussion, we see that the registration for services of appro-
priate events is the core of designing and developing solutions for event-driven
programs. Before we begin developing a complete solution for our ball-shooting
program, let us spend some time understanding events.