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

programming, it is often tempting to anticipate/poll subsequent events with
a control structure in the service routine. For example, when servicing the
left mouse button down event, we know that the mouse drag event will hap-
pen next. After allocating and defining the circle center, we have properly
initialized data to work with the HeroBall object. It may seem easier to
simply include a while-loop to poll and service mouse drag events. How-
ever, because there are other external events that may happen at any time
(e.g., Timer event, external Redraw events), this monopolizing of control
becomes a bad design decision and may cause the program to malfunction.
• An event service routine should be stateless, and individual invocations
should be independent. In terms of implementation, this essentially means
that event service routines should not define local static variables to record
application state information for subsequent invocations. Since the applica-
tion has no control over when or how often events are triggered, it follows
that it is not possible to predict the next invocation of a service routine.
This means when a service routine is invoked, it can be difficult to evalu-
ate the validity of state information stored in the local static variables. The
use of static variables in event service routines can easily lead to disas-
trously and unnecessarily complex solutions. One can always define extra
state variables in the application state to record temporary state informa-
tion that must persist over multiple event services. As we will see in our
final event-driven ball-shooting solution, the DefiningNewHeroBall flag
in Listing 1.7 is one such example.
• An event service routine should check for invocation conditions regard-
less of common sense logical sequence. For example, logically, a mouse
drag event should never happen unless a mouse down event has already oc-
curred. In reality, a user may depress a mouse button from outside of our
application window and then drag the mouse into our application window.
In this case, we will receive a mouse drag event without the correspond-
ing mouse down event. For this reason, the mouse drag service routine
should check the invocation condition that the proper initialization has in-
deed happened. Notice that in Listing 1.7, we do not include proper in-
vocation condition checking. For example, in the LMBDragRoutine() ,we
do not verify that LMBDownRotine() has been invoked (by checking the
DefiningNewHeroBall flag). In a real system, this may cause the program
to malfunction and/or crash.