Chapter 8: Understanding Events and Event-Driven Programming

Overview

As I explained in Chapter 7, “ Working with Objects,” events are a mechanism, usually associated with an object, for responding to actions such as the user clicking a button or a page being loaded. When the action occurs, an event handler is triggered (this is also called firing an event). This is the opportunity for you, the programmer, to place code that the event handler invokes.

Event-driven programming is important because most of the computer environments in use have a great deal going on. As a user, you initiate some of these “things going on” by clicking a button (or whatever), in other words, firing an event. As a user, you also use the functionality provided by program code that’s processed once you (or something) have fired an event by moving a mouse, clicking a button, or performing any of the myriad things that a user can do. If you’ve ever worked in a windowing environment—such as, well, Microsoft Windows—or an application such as Microsoft Word, or clicked around a Web browser, why, then you’ve fired a great many events!

In addition, events that you’re not responsible for triggering are firing all around you all the time! These events might be time-based, or they might have to do with resources available to a computer.

The right picture is of thousands of events, flying around, implemented as kinds of messages.

From the viewpoint of the programmer, managing all these events, and managing the code needed to “respond” to the events, sounds like a royal headache.

At first blush, the straight-ahead, linear response to a world full of thousands of events is to embed a giant conditional statement at the top of each and every program that checks to see what event is being responded to. This conditional statement would loop through all the possible events each time the program started processing code (for example, when that famous button was clicked).

There’s some logic to this, but it’s cumbersome and procedural top-down thinking, inappropriate in an event-driven world.

Conceptualizing your programs as responses to events (and only the events you care about) greatly simplifies things. For one thing, you don’t have to embed your programs within a gigantic if statement.

As I’ll show you in the second half of this chapter, it also makes sense to design many programs so that, in addition to responding to events, they fire their own custom events.

Clearly, if you think about how an event must be implemented, an event handler is a function. But there also must be a mechanism for associating the event handler with the triggering object and event. In most development environments, this amounts to a “publication” and “subscription” mechanism: By publishing (and registering) the event function, the system learns that a specialized function (the event handler) is associated with an object. Other objects that subscribe to the event invoke the event handler function when an appropriate condition occurs (the event is fired).

Objects that are prebuilt, such as the JavaScript objects shown in Table 7-1 in Chapter 7, “ Working with Objects,” or the HTML form elements that are programmable using JavaScript, have the ability to provide prebuilt events in a kind of scaffolding, sometimes called an event framework. It’s also usually possible in most development environments to add your own custom events to custom objects.

Most powerful development environments (which, of course, JavaScript in a code editor is not) provide easy access to the event framework so that it’s no big chore to add event handling code that’s processed when an event is fired.

For example, Figure 8-1 shows the Visual Studio .NET development environment loaded with a Visual Basic .NET source code project.

Figure 8-1: The Visual Studio .NET development environment loaded with a Visual Basic .NET project

In Figure 8-1, a Button control has been placed on a form (as shown in the left side of the figure). This kind of form is the basis for a window in a Windows program. The right side of the figure shows the Code Editor window. The programmer can select an event associated with the Button control from the drop-down list that’s shown (each event is marked with a lightning bolt). When an event is selected, the declaration code for the event handling function is automatically created, and all the programmer has to do is add whatever code needs to be processed when the Button’s event is fired.

We don’t have it quite so easy in JavaScript in a text editor because there’s no visual development environment provided. Then again, we don’t really need a fancy development environment!

There are two parts to this chapter. First, we’ll look at using the prebuilt events provided by an HTML form in a document loaded in a Web browser—which can be programmed using JavaScript.

You’ve already seen a fair amount of material that uses event-driven programming techniques to make examples work. In particular, the onClick event associated with a button HTML form element has got a lot of play. But if you need a refresher on events and the basic mechanics of events and JavaScript objects, you can turn back to “ JavaScript OO Lite ” in Chapter 7, “ Working with Objects.”

This chapter will be a little more rigorous. I’ll show you how to work with the most common JavaScript events, which objects provide event handlers, and which actions fire these events. In addition, I’ll show you how to “trap” events—so that your code can act to show you for yourself what is fired when.

Using Different Browsers

The predominant Web browser at this time is Microsoft Internet Explorer. However, as you may know, the first commercial Web browser was the Netscape product. Mozilla is another important browser, which is an opensource offshoot of Netscape. You can find more information about Mozilla at http://www.mozilla.org.

In the second part of this chapter, I’ll discuss how to add custom event handlers to your own custom objects. In other words, how can you effectively fire and respond to events when these events aren’t provided prebuilt by the objects in your code? Some full-featured programming languages provide more extensive ways to create your own events than does JavaScript. But this chapter should give you an idea of how to work with events.

Different Event Models

For the most part, the programs in this book have used generic JavaScript code that will run in any modern Web browser. However, in this chapter we run up against a sad fact of life: The way events work in relation to objects is slightly different in Internet Explorer than in most other major browsers (for example, Mozilla and Netscape). The same code often just won’t work for both kinds of browsers. Don’t worry: Simple button onClick events work the same way everywhere.

Although this book isn’t about Web browsers, in this chapter I’ll show you how to write code related to events that runs on Internet Explorer, Mozilla, and Netscape. I’ll also show you how to automate a test in a Web page to check which Web browser is running—so that your program can pick the appropriate code to process accordingly.

The moral of this story is that you have to carefully scrutinize the object and event model of any platform you’re targeting. This is a good lesson to bear in mind whether you’re writing code to run in a Web browser or have targeted specific applications (or operating systems).

Therefore, it’s more important for you to understand the general pattern of how events work than memorizing the details of each of the JavaScript event models—because the event and object model is likely to be different in subtle and not-so-subtle ways each time you target a new application or operating system.