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
  • 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
    • Structured Programming
    • Calling Procedures and Returning from Them
    • Coding Subroutines
    • Coding Functions
    • Coding Arguments
    • Receiving by Reference and by Value
    • Summary
    • Q&A
    • Workshop
  • 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

Structured Programming

You already know the best way to structure programs because you can use Microsoft's Visual Basic design as a guide. The small event procedures you've seen and coded are perfect examples of the correct way to code. Don't write long routines that do everything; instead, write small code procedures that each perform only one task, such as respond to a user's keystroke. If the keystroke is to trigger a bunch of things, keep the event procedure small and call other small procedures that do the detailed work.

Structured programming is a programming method you use to break long programs into numerous small procedures, putting off the details as long as possible.

For example, suppose that you need to perform the following tasks when the user clicks a Reconcile command button in a checkbook application:

1. Display checks next to cleared items.
2. Total the cleared items.
3. Total the uncleared items.
4. Recommend an action if the manual checkbook balance and the checkbook computer file's balance don't match.
5. Print a reconciliation report.

Such a detailed response to a single command button click would take many screens of code. Nevertheless, the Click() event procedure doesn't have to be many screens. Instead, you could insert a series of procedure calls that do the detailed work and keep the Click() procedure small like this:

Private Sub cmdReconcile_Click ()
   Call ClearItems ()
   Call UnClearItems ()
   If ChkBkIsBalanced () Then
      Call OutBalanceAction ()
   End If
   Call ReconcilePrint ()
End Sub

All the procedures called by a subroutine should be as small as possible and only perform a single task, or a series of calls to other procedures. When you follow this simple advice, your code becomes a structured, manageable set of routines where each sub-routine performs a single task or controls other tasks.

Not only does structured programming make writing code easier, it makes managing code simple. If your application contains a bug, you can more easily locate the bug because you follow the thread of procedures until you get to the routine that controls the logic with the bug. If your uncleared balance is incorrect, you can go directly to the procedure that computes that balance and then locate the problem without affecting lots of other code around that routine.

The called procedure is the procedure called by another procedure. The calling procedure is the procedure that triggers another's execution.

Share This