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

Coding Arguments

Variables that are local to a procedure can only be used inside that procedure. Variables declared inside a module's general section are global to the module and available throughout the entire module. Variables declared with Public instead of Dim inside the general section are global to the entire project.

You've seen throughout the first part of this book that you should avoid global variables as much as possible and use only local variables. If, however, you only use local variables but you write lots of small procedures (as you should), how can the procedures share data? If all the data is local, a called procedure has no access to the calling procedure's data. As you probably suspect, you'll share data through argument lists. When one procedure must call another procedure, and the called procedure needs information from the calling procedure, the calling procedure can send that information inside the argument list.

Suppose one procedure calculates a value and a second procedure must use that value in a different calculation before displaying a result on the form. You need to know how to pass local data from the procedure that defines the local variable to other procedures that need to work with that value.

When you call a built-in function, you pass one or more arguments to the function so that the function's internal code has data to work with. When you call your own sub-routine and function procedures, you also can pass arguments to them. The arguments are nothing more than the passing procedure's local variables that the receiving procedure needs to work with.

After you pass data, that data is still local to the original passing procedure, but the receiving procedure has the opportunity to work with those values for the time of the procedure execution. Depending on how you pass the arguments, the receiving procedure might even be able to change those values so that when the passing procedure regains control, its local variables have been modified by the called procedure.

You must declare the receiving argument list's datatypes for each argument. If you pass or receive more than one argument, separate the arguments with commas. The following statement passes the three values to a subroutine:

Call RecProc(I, J, K)

The following statement declares the RecProc() procedure:

Public Sub RecProc (I As Integer, J As Integer, K As Single)

The calling procedure already knows the datatypes of I, J, and K, but those values are unknown to RecProc(). Therefore, you'll have to code the datatype of each received argument so that the receiving function knows the datatype of each sent argument.

If a subroutine or function procedure is to receive arrays, don't indicate the array subscripts inside the argument list. The following Sub statement defines a general-purpose subroutine procedure that accepts four arrays as arguments:

Public Sub WriteData (GNames() As String, CBalc() As Currency, CDate() As Variant, CRegion

      
   () As Integer)

The built-in UBound() function returns the highest subscript that's defined for any given array. The following statement, which might appear inside the WriteData() subroutine, stores the highest possible subscript for the CNames() array, so the subroutine won't attempt to access an array subscript outside the defined limit:

intHighSub = UBound(CNames)

Share This