C H A P T E R T E N Event-Driven Programming Programming Languages – Principles and Paradigms by Allen Tucker, Robert Noonan

Background: Previous programming paradigms have emphasized the process for solving a problem. Once the program was complete we would:  provide input  run the program  display the answer(s) Things always happened in the same sequence. The program always terminated when the process was complete (except for some Prolog programs we will not mention).

Background: Event-driven programs do not have a set sequence of instructions to execute. They also do not have a predetermined finish. The most common example of event-driven programming is found in graphical user interfaces (GUIs):  M$ Windows  Apples Mac OS  X11 under *nix Other applications include embedded systems, control systems, sensor systems like home security, etc.

Event-driven Languages: Support of even-driven programming is often grafted on to existing languages, for example X11 is implemented as a set of function libraries under C and class libraries under C++. Some languages were designed around the needs of event-driven applications such as Visual Basic and Tcl/Tk. With the advent of the word wide web (WWW) event- driven programming has gained in popularity as a way to add interaction to web pages. Such interaction is programmed in a number of languages including JavaScript and Java. We will be using Java to implement Applets, programs intended to run inside a web browser.

Imperative vs. Event-Driven Paradigms Figure 10.1 Computation is a function from its input to its output, made up of a sequence of steps that produce some result as its goal. ** Computation is a community of persistent entities coupled together by their ongoing interactive behavior. Beginning and end are special case that can often be ignored.

Event-driven Programs Input to event-driven programs come from event sources; sensors, input devices, objects on a web page. Events occur asynchronously and are placed in an event queue as they arise. Events are removed from the event queue and processed (“handled”) by the program’s main processing loop. As a result of handling an event the program may produce output or modify the value of a state variable. There is no predefined starting or stopping point. Java provides support for event-driven programming through certain classes and methods that can be used to design program interaction.

Java Class AWTEvent and Its Subclasses* Figure 10.2 Events in Java are defined by subclasses of the AWTEvent abstract class.

Java Event Classes Every event source in a program can generate an event that is a member of one of the classes on the previous slide. For example, if a Button is an event source, it generates events that are members of the ActionEvent class. Objects that can be event sources are members of subclasses of the Component abstract class. This class and its subclasses are shown on the next slide, where we will find the Button object.

Subclasses of Component That Can Be Sources of Events Figure 10.3

Java EventListener Class Interface: For a program to handle an event it must be equipped with a listener that will recognize when a particular event has occurred. For example, for a program to be able to “hear” that a button has been selected it must send an addActionListener message to the button object. The EventListener class and its subclasses provide the interface for recognizing events by setting up appropriate listeners for component objects. The EventListener class interface and its subclasses are shown on the next slide.

Java EventListener Class Interface and Its Subclasses* Figure 10.4 To respond to events we need to implement special methods called handlers. Each class of events predefines the names of the handlers that can be written for it…

Handlers Required for Button, Menu, Text Typing, and Mouse Events Figure 10.5

Initial Frame Design for a Graphical Drawing Tool Figure 10.7

Overall Structure of a Java Applet Figure 10.6

Next time… example : Writing A Java Applet