Event-driven programming

Because the code is for checking for events and the main loop are common amongst applications, many programming frameworks take care of their implementation and expect the user to provide only the code for the event handlers. In this simple example, there may be a call to an event handler called OnKeyEnter() that includes an argument with a string of characters, corresponding to what the user typed before hitting the ENTER key. To add two numbers, storage outside the event handler must be used. The implementation might look like below.

globally declare the counter K and the integer T.
OnKeyEnter(character C)
{
   convert C to a number N
   if K is zero store N in T and increment K
   otherwise, add N to T, print the result and reset K to zero
}

While keeping track of history is normally trivial in a sequential program because event handlers execute in response to external events, correctly structuring the handlers to work correctly when called in any order can require special attention and planning in an event-driven program.

The first step in developing an event-driven program is to write a series of subroutines, or methods, called event-handler routines. These routines handle the events to which the main program will respond. For example, a single left-button mouse-click on a command button in a GUI program may trigger a routine that will open another window, save data to a database or exit the application. Many modern-day programming environments provide the programmer with event templates, allowing the programmer to focus on writing the event code.

The second step is to bind event handlers to events so that the correct function is called when the event takes place. Graphical editors combine the first two steps: double-click on a button, and the editor creates an (empty) event handler associated with the user clicking the button and opens a text window so you can edit the event handler.

The third step in developing an event-driven program is to write the main loop. This is a function that checks for the occurrence of events, and then calls the matching event handler to process it. Most event-driven programming environments already provide this main loop, so it need not be specifically provided by the application programmer. RPG, an early programming language from IBM, whose 1960s design concept was similar to event-driven programming discussed above, provided a built-in main I/O loop (known as the "program cycle") where the calculations responded in accordance to 'indicators' (flags) that were set earlier in the cycle.

In PL/I, even though a program itself may not be predominantly event-driven, certain abnormal events such as a hardware error, overflow or "program checks" may occur that possibly prevent further processing. Exception handlers may be provided by "ON statements" in (unseen) callers to provide cleaning routines to clean up afterwards before termination, or to perform recovery operations and return to the interrupted procedure.