vel16.htm

简单的说明如何使用VB,非常适合初学使用者,而且是用图表来解说的

<FONT SIZE=5 COLOR="#FF0000"><B>Module Variables</B></FONT></CENTER></H3>

<BR>

<P><FONT COLOR="#FF8000"><B><I>Concept: </I></B></FONT>Module variables are also defined in (general) 
procedures. Rather than use Global, you use Dim to define module variables. Module variables are available to all procedures within the module in which 
they are defined. Therefore, module variables are more limited in scope than global variables because 
they aren't available globally.

<BR>

<P>Module variables are considered slightly safer variables than global variables. Only the module in which you define module variables can access and change those variables. Therefore, technically, you could have two 
different modules in a single 
application, and each module could have the same module variable with the same name. Each module's module variables, however, would be separate variables. The code that accesses and changes the module variable within one of 
the modules changes only that 
module's variable.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><B>Caution: </B>Despite the fact that two modules within the same application can be named the same variable name without conflict, you 
should try not to duplicate variable names because of the maintenance confusion such double-defined variables can 
cause.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>Unlike global variables, which you can define only in non-form 
modules, you can define module variables in the form's module or within any external module in your program. Generally, programmers rarely use module variables; most applications need either 
global values that are available through the application or 
local values that are specifically available only to individual procedures.

<BR>

<P><FONT COLOR="#FF8000"><B><I>Stop and Type: </I></B></FONT>Listing 16.2 defines two module variables. The module variables must be defined in the (general) procedure of 
any module within the application.

<BR>

<P><FONT COLOR="#FF8000"><B><I>Review: </I></B></FONT>Module variables, defined with Dim in the (general) procedure of any module, are available to any procedure within that module.

<BR>

<P>

<FONT 
COLOR="#000080"><B>Listing 16.2. Code that defines two module variables.</B></FONT>

<BR>

<PRE>

<FONT COLOR="#000080">1: Dim M1 As Integer

2: Dim M2 As Double</FONT></PRE>

<P><FONT COLOR="#FF8000"><B><I>Analysis: </I></B></FONT>Lines 1 and 2 define two 
module variables named M1 and M2. The definitions must appear within some module's (general) procedure. The variables aren't global because Dim defines them instead of Global.


<BR>

<BR>

<A NAME="E68E122"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 
COLOR="#FF0000"><B>Local Variables&#151;The Safest Variables</B></FONT></CENTER></H3>

<BR>

<P><FONT COLOR="#FF8000"><B><I>Concept: </I></B></FONT>Local variables are available only within the procedures in which they are defined. Use the Dim statements 
to define local variables. You may define local variables only within individual 
non-declarations procedures; you can't define local variables within the (general) procedure.

<BR>

<P>Global and module variables aren't considered as safe as local 
variables. Suppose that only three procedures within a large application need access to a variable. If you limit that variable's scope to those three procedures, you won't accidentally 
change those variables in other procedures by using the variables 
where you never intended to use them.

<BR>

<P>Most of your program's working variables should be local. You'll define those variables, as you've been doing throughout this book, and those variables aren't available outside their procedures. All of the 
Dim statements that you saw in this book, 
before this unit, defined local variables.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><B>Caution: </B>Local variables defined with Dim last <I>only</I> as long as the procedure's execution 
lasts.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>When a procedure ends, its local variables defined with Dim go away and their values disappear. If execution were to re-enter that procedure, Visual Basic would define those variables 
all over again and initialize them again. Therefore, if execution 
enters a procedure a second time, the values of all local variables defined with Dim the last time that the procedure executed would no longer be in effect.

<BR>

<P><FONT 
COLOR="#FF8000"><B><I>Stop and Type: </I></B></FONT>Listing 16.3 shows a command button's event procedure that defines a local variable and uses that variable and a module variable to compute a value for a label's caption.

<BR>

<P><FONT 
COLOR="#FF8000"><B><I>Review: </I></B></FONT>When you declare a variable at the top of a procedure using Dim, you declare a local variable that Visual Basic recognizes only for the life of that procedure.

<BR>

<P>

<FONT COLOR="#000080"><B>Listing 16.3. 
Using a module and a local variable within a procedure.</B></FONT>

<BR>

<PRE>

<FONT COLOR="#000080">1: Sub cmdInvFactor_Click()

2: ' Adds an inventory factor to a module-level

3: ' inventory total when the user clicks the

4: ' inventory command 
button

5: Dim FactAdd As Single

6: FactAdd = .13

7: ' Add to the module variable named InventoryTotal

8: lblInvent.Caption = InventoryTotal + FactAdd

9: End Sub</FONT></PRE>

<P><FONT COLOR="#FF8000"><B><I>Analysis: </I></B></FONT>Line 1 begins a new 
event procedure. Therefore, any variable defined within the procedure, using Dim, must be a local variable. Line 5 defines the local variable named FactAdd. Line 8 then adds 
FactAdd to a module variable named InventoryTotal to compute the final label's 
result.

<BR>

<BR>

<A NAME="E68E123"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Passing Arguments</B></FONT></CENTER></H3>

<BR>

<P><FONT COLOR="#FF8000"><B><I>Concept: </I></B></FONT>Local variables are considered the safest, 
and generally the best kinds of variables to define. However, there will be many times when a subroutine or function procedure needs a value from another's 
local variable. For example, suppose that one procedure calculates a value, and a second procedure 
must use that value in a different calculation before displaying a result on the form. This section explains how to pass local data <I>from</I> the procedure 
that defines the local variable <I>to</I> other procedures that need to work with that value.


<BR>

<P>When you call the built-in functions, 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 subroutine 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.

<BR>

<P>Once 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. 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.

<BR>

<P>Figure 
16.2 illustrates the terminology used in passing and receiving arguments from one procedure to another. A procedure, referred to as the <I>calling procedure</I>, passes one or more of its local variables, referred to as <I>arguments</I>, to the 
receiving 
procedure. The only reason that parentheses exist following a procedure name is to hold the arguments sent to the receiving function.

<BR>

<P><B> <A HREF="16vel02.gif">Figure 16.2. Showing the proper procedure-calling terminology.</A></B>

<BR>


<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><B>Note: </B>As you already know, if the receiving procedure is a function procedure, the function procedure usually returns a value to the calling procedure.</NOTE>

<BR>

<HR ALIGN=CENTER>


</BLOCKQUOTE></BLOCKQUOTE>

<P>In Figure 16.2, the receiving arguments are I, J, and K. The receiving procedure uses the same names are the calling procedure in this figure, and that's usually the case. However, you don't have to use the same names. In 
other words, if RecProc() 
received the three variables as X, Y, and Z, then RecProc() would have three variables to work with named X, Y, and Z, and those three variables would have the same values as I, J, and K in the calling procedure. Therefore, the 
receiving names don't have 
to match the passed names, although they typically do to eliminate any confusion.

<BR>

<P>Declare the data type of all received arguments. If you must pass and receive more than one argument, separate the passed arguments and 
the received arguments (along with their declared data types), with commas. The following statement passes the three 
values to the subroutine in Figure 16.2:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">Call RecProc(I, J, K)</FONT></PRE>

<P>The following 
statement begins RecProc() procedure:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">Sub RecProc (I As Integer, J As Integer, K As Single)</FONT></PRE>

<P>The calling procedure already knows the data types of I, J, and K, but those values are unknown to 
RecProc(). Therefore, you'll have to code the data type of <I>each</I> received argument so that the receiving function knows the data type of the sent 
arguments.

<BR>

<P>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:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">Sub WriteData (CNames() As String, CBalc() As Currency, 
CDate() As Variant, CRegion() As Integer)</FONT></PRE>

<P>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:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">HighSub = UBound(CNames)</FONT></PRE>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR 
ALIGN=CENTER>

<BR>

<NOTE><B>Warning: </B>Don't forget that the Call statement is funny about the argument parentheses. If you use Call, you must also enclose the arguments in parentheses. You may omit the Call keyword, but if you do, omit the parentheses 
as well. Here is an 
equivalent Call statement as that shown in Figure 16.2:

<BR>RecProc I, J, K ' No Call, no parens!</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P><FONT COLOR="#FF8000"><B><I>Stop and Type: </I></B></FONT>Suppose that 
you're writing a set of programs for a bookstore's inventory and customer tracking purposes. The owners of the bookstore require that the user enter a category code that describes 
the kind of item being tracked or bought, and the program will print the 
description of that category as the purchase is entered or as the item is tracked through inventory. In other words, you'll ask the user for a category code of 1, 2, 3, 4, or 5, and 
the program will return a description in a string message variable 
describing that category. The following Select Case would work:

<BR>

<PRE>

<FONT COLOR="#000080">Select Case CatCode

 Case 1:

 CatMessage = &quot;Book&quot;

 Case 2:

 CatMessage = &quot;Magazine&quot;

 Case 3:

 CatMessage = &quot;Newspaper&quot;

 
Case 4:

 CatMessage = &quot;Writing Supplies&quot;

 Case 5:

 CatMessage = &quot;Software&quot;

 Case Else:

 CatMessage = &quot;The category code is in error&quot;

End Select</FONT></PRE>

<P>The problem is that this lengthy Select Case is needed 
throughout the program and needed by several other Visual Basic programs that you're writing as well. You're much better off storing this code as a general-purpose function procedure such as the one 
shown in Listing 16.4, and calling the function from 
wherever the code is needed, like this:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">CatDesc = DispCatCode$(CatCode) ' CatDesc is a string</FONT></PRE>

<P>The function procedure enables you to pass the category code number argument and return the string 
description that matches that argument. As long as you store the procedure in a module file, any application that you add the module file to will be able 
to call the function and receive the message.

<BR>

<P><FONT COLOR="#FF8000"><B><I>Review: 
</I></B></FONT>By passing arguments between function and subroutine procedures, your procedures can share local data. If a procedure doesn't need access to another's local variable, you'll never pass that procedure 
the variable. By passing data only as 
needed, you'll be provided data access on a need-to-know basis; that is, only those procedures that need access to data get access. If all of your variables are global, any procedure could inadvertently change 
another's variable, and such logic errors are 
often difficult to find.

<BR>

<P>

<FONT COLOR="#000080"><B>Listing 16.4. A general-purpose function procedure that you can call from any other procedure.</B></FONT>

<BR>

<PRE>

<FONT COLOR="#000080">1: Function DispCatCode$(CatCode As Integer)

2: Dim 
CatDesc As String

3: Select Case CatCode

4: Case 1:

5: CatMessage = &quot;Book&quot;

6: Case 2:

7: CatMessage = &quot;Magazine&quot;

8: Case 3:

9: CatMessage = &quot;Newspaper&quot;

10: Case 4:

11: CatMessage = &quot;Writing Supplies&quot;

12: 
Case 5:

13: CatMessage = &quot;Software&quot;

14: Case Else:

15: CatMessage = &quot;The category code is in error&quot;

16: End Select

17: DispCatCode = CatMessage ' Returns a description

18: End Function</FONT></PRE>

<P><FONT 
COLOR="#FF8000"><B><I>Analysis: </I></B></FONT>The DispCatCode$() function could be stored in an external module file along with several other subroutine and function procedures that your applications often need. The module file acts like a 
toolchest with 
tools (procedures) that you can use (call) any time you need them.

<BR>

<P>Line 1 defines the procedure to be a function that receives one integer argument from the calling code. Line 2 defines a local string variable that the Case statements will use as 
a temporary storage location for the appropriate description. Lines 4 
through 15 then test the passed integer to see whether the category code is 1, 2, 3, 4, 5, or another value that would indicate an error. Line 17 ensures that the appropriate message is 
returned to the calling procedure.

<BR>

<BR>

<A NAME="E68E124"></A>

<H3 ALIGN=CENTER>