Sams Teach Yourself Visual Basic 6 in 24 Hours

By Greg Perry

• Table of Contents
  • Copyright
  • About the Author
  • Acknowledgments
  • Introduction
  • Who Should Read This Book
  • What This Book Will Do for You
  • Can This Book Really Teach Visual Basic in 24 Hours?
  • What You Need
  • Files on the Visual Basic Distribution CD-ROM
  • Conventions Used in This Book
  • Enough! Time Is Ticking!
  • Part I: Introducing Visual Basic
  • Hour 1. Visual Basic at Work
  • Hour 2.Analyzing Visual Basic Programs
    • Event-Driven Programs
    • Control Events
    • Analyzing Sample Applications
    • Naming Objects
    • Running Applications
    • Where's the Code?
    • Event Procedures
    • Properties and Event Procedures
    • Generating an Application from Scratch
    • Summary
    • Q&A
    • Workshop
  • Hour 3.Controls and Properties
  • Hour 4.Examining Labels, Buttons, and Text Boxes
  • Part II: Coding the Details
  • Hour 5.Putting Code into Visual Basic
  • Hour 6.Message and Input Boxes
  • Hour 7.Making Decisions
  • Hour 8.Visual Basic Looping
  • Part III:Putting Code to Work
  • Hour 9.Combining Code and Controls
  • Hour 10.List Boxes and Data Lists
  • Hour 11.Additional Controls
  • Hour 12.Dialog Box Basics
  • Part IV:Programming with Data
  • Hour 13.Modular Programming
  • Hour 14.Built-In Functions Save Time
  • Hour 15.Visual Basic Database Basics
  • Hour 16.Printing with Visual Basic
  • Part V:Sprucing Up Programs
  • Hour 17.Menus and Visual Basic
  • Hour 18.The Graphic Image Controls
  • Hour 19.Toolbars and More Graphics
  • Hour 20.Writing Correct Applications
  • Part VI:Advancing Visual Basic Applications
  • Hour 21.Visual Basic and ActiveX
  • Hour 22.Object Basics
  • Hour 23.Distributing Your Applications
  • Hour 24.Online Visual Basic
  • Part VII:Appendixes
  • Appendix A.Operator Precedence
  • Appendix B.Answers
  • Appendix C.Using the CD-ROM

Event-Driven Programs

Lots can happen when a Windows program executes. For example, consider the Microsoft Excel screen in Figure 2.1. What can happen next? What exactly will the user at the keyboard do? The user might click a toolbar button, select a menu option, press F1 to get help, scroll the window, enter additional numbers or formulas, edit existing worksheet cells, or switch to another program.

Figure 2.1 A Windows program never knows what will happen next.

In the old days of programming (less than a decade ago), before windowed environments became so popular, the program dictated what the user could next do. The program might ask a question, and the user could answer the question and nothing else until the question was answered. The program might display a menu of options. Although the user had a choice of options, he only had the choice of a menu selection. If he wanted to move to another part of the program, he couldn't unless such a move was part of the currently displayed menu.

The multitasking, multiuser windowed environments changed everything. Today's Windows program has no idea what might happen next. The program must offer a plethora of choices that range from menu options to various controls and data-entry locations, and the program just has to wait and see what happens.

When the programs lost control, users gained. Users can now perform any one of many tasks. The problem for the programmer is responding to users' actions when so many actions are possible. Fortunately, Microsoft designed Windows to be elegant not only for the user but for the programmer as well. When virtually anything happens in the Windows environment, Windows generates an event. An event might be a keypress, an internal clock tick, a menu selection, a mouse click, a mouse movement, a task switch, or one of many hundreds of other possible events.

An event is something that happens, usually but not always, due to the user at the keyboard, during a program's operation.

Your program doesn't have to wait around for the user to do something specific. In text-based programming days, you would write one big program that guided the user through the execution of the code step-by-step. The program would take the user to a menu, ask the user questions, and offer only a limited set of choices. In many ways, a Visual Basic program is nothing more than a collection of small routines. These routines, called event procedures, handle individual events. If and only if an event occurs for which you've written an event procedure does that event procedure execute. You don't have to do anything special to execute the event procedure-just write the code. In other words, your program responds to events by supplying a matching event procedure and your program ignores events if you haven't written an event procedure.

Share This