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 you’ve written one or more event handlers for your UI, you have a complete working UI. Now you just have to attach this UI to a working program.
Writing your program
Some people write the program first and then design a UI around it. Other people design the UI first and then write the program to work with it. The whole point of event-driven programming is to separate your program from your UI so you can focus on making each part work individually.
Event-driven programming focuses mostly on designing a UI and making it work, but it does little to help you write your actual program. To write your program, you can use structured programming or object-oriented programming (or both, or neither).
After you’ve written your program, you “attach” the program to your UI by writing event handlers. Event handlers “glue” your UI to your actual program. With event-driven programming, you can be pretty sure that your UI will always work perfectly. You just have to worry about errors in your main program.
Object-Oriented Programming
Structured programming helps you organize and divide your program into smaller, more manageable pieces. For small to medium programs, dividing a program into smaller programs is fine, but the larger your program gets, the more smaller programs you’ll have to worry about. Eventually, computer scientists discovered that they needed another technique for dividing large programs into parts. They called this new technique object-oriented programming (often abbreviated as OOP). Object-oriented programming solves two glaring problems with structured programming: reusability and modeling.
Reusability means that you can collect smaller programs that work together, store them in a larger group called an object, and then plug
