i
i
i
i
i
i
i
i
476 19. Building Interactive Graphics Applications
• (B) Continuous outer loop. Since this is a general control structure to
be shared by all event-driven programs, there is no way to determine the
termination condition. User program are expected to override appropriate
event service routines and terminate the program from within the service
routine.
• (C) Stop a nd wait. Instead of actively polling the user for actions (wasting
machine resources), the MainEventLoop() typically stops the entire appli-
cation process and waits for asynchronous operating system calls to re-
activate the application process in the presence of relevant user actions.
• (D) Events and central parsing switch statement. Included in this state-
ment are all possible actions/events (cases) that a user can perform.
Associated with each event (case) is a default behavior and a toggle
that allows user applications to override the default behavior. During
SystemInitialization(), the user application can register an alternate service
routine for an event by toggling the override.
To develop an event-driven solution, our program must first register event service
routines with the GUI system. After that, our entire program solution is based on
waiting and servicing user events. While control-driven programming solutions
are based on an algorithmic organization of control structures in the main() func-
tion, an event-drivenprogramming solution is based on the specification of events
that cause changes to a defined application state. This is a different paradigm for
designing programming solutions. The key difference here is that, as program-
mers, we have no explicit control over the algorithmic organization of the events:
over which, when, or how often an event should occur.
The program in Figure 19.6 implements the left mouse button operations for
our ball shooting program. We see that during system initialization (A), the pro-
gram defines an appropriate application state (A1) and registers 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. No-
tice 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.
Figure 19.7 shows how our program from Figure 19.6 is linked with the pre-
defined MainEventLoop() from the GUI system. The MainEventLoop() calls the
SystemInitialization() function defined in our solution (A). As described, after
the initialization, our entire program is essentially the three event service rou-
tines (D1, D2, and D3). However, we have no control over the invocation of