Forcing each program to display menus and windows had two advantages for users:
It made using a computer much easier. Instead of having to type in commands, users could just click the command they wanted to use.
It’s fairly easy to figure out how to use different types of programs. After you understand that you can choose the Print command from the File menu, you know how to print in any program — whether it’s a word processor, a database, or an image-editing program.
Unfortunately, although drop-down lists made programs easy for users, they made writing programs much harder for programmers:
Programmers had to write extra commands just to display all these fancy drop-down lists and windows. (Even worse, programmers had to make sure all those extra commands used to create drop-down lists and windows actually worked correctly.)
Programmers now had to write programs that could react to whatever command the user chose. Instead of presenting the user with options in a specific, predictable order, programs had to handle the unpredictable choices of the user.
To solve this dual problem of creating drop-down lists and knowing how to handle the different commands the user may choose at any given time, computer scientists developed event-driven programming.
In event-driven programming, an event is something that the user does or that the computer must respond to. The user might click a drop-down list or click a button displayed in a window. The computer might need to respond to an incoming email or a file being added to a directory. Event-driven programming simply focuses on displaying different commands onscreen and then handling these different events when they occur.
Event-driven programming divides programming into three distinct parts:
The user interface (UI): The commands the user sees onscreen
The event handler: The part of the program that reacts to the commands the user chooses from the UI
The actual program: The part of the program that actually does something useful, such as drawing pictures or predicting the winners of horse races
In the old days, creating a UI essentially tripled a programmer’s work. You had to:
1 Write your program.
2 Write commands to create a UI.
3 Write commands to make your UI actually work.
Instead of forcing you to write commands to display drop-down lists and windows onscreen, a tool called a rapid application development (RAD) program lets you visually design your UI, such as the number, placement, and size of buttons.
After you’ve designed your UI (without having to write a single command to do it), you can write short programs that respond to everything the user could possibly do, which is called an event. If the user clicks a drop-down list, that’s an event. If the user clicks a button in a window, that’s a different event. When you write a small program to handle an event, the program is called an event handler.
Without event-driven programming, you’d be forced to write commands to create a UI and more commands to make the UI work. With event-driven programming, you just have to write commands to make your UI work. The fewer commands you have to write, the faster you can create a program and the easier the program will be to read, understand, and modify later.
Basically, event-driven programming divides programming into three distinct steps: designing the UI, writing event handlers to make the UI work, and writing the actual program.
Designing a user interface
The main advantage of event-driven programming is how quickly it allows you to design a UI without writing a single command whatsoever. Instead of writing commands, you create a UI using a two-step process:
1 Visually draw your UI on a window by choosing which UI parts you want, such as buttons, check boxes, or menus, as shown in Figure 2-5.After you’ve drawn your UI, you wind up with a generic UI.FIGURE 2-5: Designing a UI involves drawing what you want to appear on your program's UI.
2 Customize each part of your UI by defining its appearance and behavior.To customize part of a UI, you must modify that UI’s properties. Each part of your UI contains properties that define its appearance and behavior. For example, if you wanted to change the size of a check box, you’d modify that check box’s Width or Height property, as shown in Figure 2-6.
With event-driven programming, designing a UI involves drawing your UI and then customizing it by changing its properties. After you’ve designed your UI, it will appear to work, but it won’t actually do anything until you write an event handler.
FIGURE 2-6: Properties define how each part of a UI looks and behaves.
Writing event handlers
The whole purpose of an event handler is to work as a middleman between your actual program and your program’s UI. To create an event handler, you need to identify the following:
A UI item, such as a button or a check box
The event to respond to, such as a click of the mouse
An event handler responds to a certain event triggered by a specific UI item, as shown in Figure 2-7. A UI item can have one or more event handlers so it can respond to different types of events, such as the user clicking a mouse button or pressing a key. A single event handler can respond to the same event coming from different UI items such as three different buttons.
FIGURE 2-7: An event handler tells the UI how to behave when the user does something, such as click the mouse over a button.
The user can do dozens of different possible events, but some common events are clicking the mouse or pressing a key. Event handlers typically do one of three things:
Identify what the user did, such as click a button
Retrieve information from the UI, such as when the user types something in a text box
Display information to the user, such as an error message
After