Wallace Wang

Beginning Programming All-in-One For Dummies


Скачать книгу

something called a graphical user interface (GUI). A GUI displays multiple options to the user in the form of drop-down lists, windows, buttons, and check boxes. Suddenly, instead of the computer dictating what the user could do at any given time, the user could tell the computer what to do at any given time, just by choosing one of many available commands.

      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.

      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.

      

The most popular language that defined event-driven programming is Visual Basic although other languages have adopted event-driven programming as well.

      

Event-driven programming doesn’t replace structured programming; it supplements it. Structured programming techniques are useful for helping you write your program. Event-driven programming is useful for helping you design a UI for your 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.

Snapshot of properties define how each part of a UI looks and behaves.

      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

Snapshot of an event handler tells the UI how to behave when the user does something, such as click the mouse over a button.

      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