vel15.htm

来自「简单的说明如何使用VB,非常适合初学使用者,而且是用图表来解说的」· HTM 代码 · 共 1,355 行 · 第 1/3 页

<BR>

<NOTE><I>Definition: </I>To <I>call</I> a subroutine means to execute the subroutine from elsewhere in 
the program.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>Suppose that your company has a specialized routine for calculating a cost of sales value. In writing a sales-computation data entry program, you find that you must execute this 
code several different places in the program. In other words, you never 
execute the routine over and over in a loop; instead, you may find that three or four different event procedures need to include this same calculation. Rather than type the exact code 
in three or four different places, type the code <I>just once</I> in its 
own subroutine and <I>call</I> that subroutine from each event procedure that needs the calculations.

<BR>

<P>Follow these steps to create a non-event subroutine procedure:

<BR>


<OL>

<LI>Make up a name for the procedure using the same naming conventions that you use for variables. Be sure to name the subroutine something meaningful. If you were computing cost of sales, the name CostOfSales would be a perfect name.

<BR>

<BR>


<LI>Open the Code window if it's not already open.

<BR>

<BR>

<LI>Press the PgDn key or click the Code window's vertical scroll bar to move the Code window down to the end of any event procedure. In other words, position the Code window's text cursor to 
the end any End Sub statement that you can find.

<BR>

<BR>

<LI>On a blank line below the End Sub statement, type the Sub statement followed by your new subroutine name. In other words, you would type <B>Sub CostOfSales</B> after any event procedure's 
End Sub statement.

<BR>

<BR>

<LI>As soon as you type the Sub statement, Visual Basic recognizes that you're starting a new subroutine. Visual Basic finishes the End Sub wrapper line and displays your new subroutine by itself in the Code window, as shown 
in Figure 15.2.

<BR>If you were to open the Proc dropdown list, you would see the new CostOfSales general purpose subroutine among the list of procedures.

<BR>

<BR>



<P><B> <A HREF="15vel02.gif">Figure 15.2. Visual Basic gives your subroutine its own 
place in the Code </B><B>window.</A></B>

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><B>Note: </B>Notice that Visual Basic always adds parentheses after all subroutine names. Nothing you do will get rid of those parentheses. You'll 
use those parentheses in the next unit.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<LI>You can now insert the body of the subroutine in the middle of the two wrapper statements. As you add a line and press Enter, Visual Basic adds 
additional lines, so the subroutine grows as large as needed. Listing 15.2 contains a sample cost of sales 
subroutine that could be used for the procedure.

<BR>

<BR>

</OL>

<P>

<FONT COLOR="#000080"><B>Listing 15.2. The cost of sales 
subroutine.</B></FONT>

<BR>

<PRE>

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

2: ' Computes a cost of sales and displays

3: ' that cost in the appropriate label

4: Dim GrossSales As Currency

5: Dim CostSales As Currency

6: Dim OverHead As Single


7: Dim InventoryFctr As Single

8: Dim PilferFctr As Single

9: 

10: ' Store initial values from the form

11: GrossSales = txtGross.Text

12: InventoryFctr = txtTotalInv.Text * .38

13: PilferFctr = txtPilfer.Text

14: OverHead = .21 ' Fixed overhead


15: 

16: CostSales = GrossSales - (InventoryFctr * GrossSales)

17: CostSales = CostSales - (PilferFctr * GrossSales)

18: CostSales = CostSales - (OverHead * GrossSales)

19: lblCost.Caption = Format$(CostSales, &quot;Currency&quot;)

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

<P><B> <A HREF="15vel03.gif">Figure 15.3. You can use the New Procedure dialog box to open a new </B><B>procedure.</A></B>

<BR>

<P>Although the body of the cost of sales subroutine is only 18 lines long, you certainly don't want to type 
those same 18 lines in every event procedure that needs to execute those 18 lines. If you've typed the code in its own subroutine as shown in 
Listing 15.2, you never have to type that code again. Instead, you'll just call that subroutine from every place 
in the program that needs the code executed.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><B>Tip: </B>You can take a shortcut when you want to open a new procedure. Select the View New Procedure from the menu bar. Visual Basic displays 
the small New Procedure dialog box shown in Figure 15.3. Clicking Sub opens a new subroutine procedure, 
and clicking Function opens a new function procedure (described later in this unit). Type the new procedure name in the Name text box and click OK. 
Visual Basic will open the new procedure and type the wrapper lines for you.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>The Call statement executes subroutines. Here is the format of Call:

<BR>

<BR>

<PRE>

<FONT 
COLOR="#000080">[Call] subName [(argumentList)]</FONT></PRE>

<P><A HREF="vel16.htm">Unit 16</A> describes the use of the <I>argumentList</I>. Not all procedures will contain an argument list. Call is optional, but if you do use the Call keyword when you 
call subroutines, you also must include the parentheses. Just 
remember: If no Call, no parentheses; if Call, use parentheses. Either way, the argument list may or may not be required.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>


<NOTE><B>Tip: </B>You can move from procedure to procedure inside the Code window using the PgUp and PgDn keys. If you press F2, the shortcut access key for the Window Procedures command, Visual Basic displays a list of procedures; select a procedure and 

Visual Basic takes you to that procedure in the Code window.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>You'll learn about the argument list in the next unit. For now, concentrate on the use of Call. Whenever any procedure in your 
program needs to trigger the execution of the CostOfSales subroutine, you'll only need to code the following Call statement:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">Call CostOfSales () ' Executes all of the subroutine</FONT></PRE>

<P>The following 
statement is equivalent because, without Call, you don't need the parentheses:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">CostOfSales ' Executes all of the subroutine</FONT></PRE>

<P>If three different procedures need the cost of sales routine calculated, 
isn't it easier (and less error-prone) to type the code <I>once</I> in its own subroutine and then simply call that subroutine from every place in the program that needs it? You 
can call subroutine procedures from event procedures as well as from other 
non-event subroutine procedures. Figure 15.4 shows the program flow when several event and subroutine procedures call the CostOfSales procedure. When one of the calling procedures 
calls CostOfSales, the CostOfSales takes over, executes, and the program's 
execution flow continues where it left off before taking time off.

<BR>

<P><B> <A HREF="15vel04.gif">Figure 15.4. The subroutines work like detours inside your program.</A></B>

<BR>

<P>The Call statement also executes event procedures. You can, even if 
the user didn't trigger an event, trigger any event from within the code by using Call to execute the event procedure. Suppose that the Exit command button performs several 
end-of-program tasks such as erasing the form, asking the user's permission to 
exit inside a message box, writing the last of data files to disk, and printing a final report on the printer. If you find that you need to perform a program exit even if the 
user has yet to click Exit, you can call the cmdExit_Click() event procedure 
yourself.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><B>Note: </B>If you ever need to exit a subroutine procedure before the procedure's normal termination&#151;for example if the user cancels a subroutine input box&#151;use the Exit 
Sub statement.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P><FONT COLOR="#FF8000"><B><I>Review: </I></B></FONT>When the same set of code lines needs to appear in more than one location in your program, consider putting those lines in 
their own subroutine procedure. You'll need to start a new procedure only if 
you use the Sub&quot; or select the New Procedure command from the View menu. Place a Call to the subroutine procedure in all other program locations where you want the 
subroutine code to execute. You can call either a subroutine procedure or an event 
procedure using Call. When Visual Basic completely executes the procedure, Visual Basic returns execution to the code that performed the Call, and execution resumes at the 
statement following the Call.

<BR>

<BR>

<A NAME="E68E115"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>External .BAS Modules</B></FONT></CENTER></H3>

<BR>

<P><FONT COLOR="#FF8000"><B><I>Concept: </I></B></FONT>Over time, you'll 
write several routines, such as the previous section's CostOfSales subroutine procedure, that you will need in more than one application. Rather than write the same subroutine 
procedure in every application, you can store the subroutine procedure in a 
module file, along with other common procedures that you write, and add that file to any application that uses the file's procedures.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><I>Definition: </I>A <I>module</I> contains a form and 
the procedures used by that form.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>Every program that you've seen so far in this book has consisted of single modules. A module is a collection of all event procedures, subroutine procedures, 
and function procedures, along with a form holding the controls. With the Visual Basic Primer 
system, you can add additional code modules to your form's module. A code module is an external file, stored separately on the disk, that contains the code of 
procedures that you write. These procedures are general-purpose procedures that perform 
calculations on data that you'll soon learn to pass to and from those procedures.

<BR>

<P>The CONSTANT.TXT file is a specialized kind of module that contains only a 
(general) procedure. Although you could add additional procedures to CONSTANT.TXT, you should neither add nor take away from the contents of CONSTANT.TXT. With each version of 
Visual Basic that Microsoft releases, Microsoft updates the contents of 
CONSTANT.TXT, and you'll want to replace the old CONSTANT.TXT file with the new one when and if you upgrade to a different version of Visual Basic.

<BR>

<P>You can add additional code modules to your program by selecting File New Module (or by clicking 
the New Module toolbar button, the second toolbar button from the left). As soon as you request a new module, Visual Basic opens a new Code window for that 
module. Visual Basic automatically names the first module that you add MODULE1.BAS (adding that 
file to the Project window's file list for that application). If you were to add a second module, Visual Basic would name that module MODULE2.BAS, and so on. 
Figure 15.5 shows the new Code window that opens when you add a new module to an application.


<BR>

<P><B> <A HREF="15vel05.gif">Figure 15.5. The new Code window from the MODULE1.BAS external module </B><B>file.</A></B>

<BR>

<P>Once you add code to a module file, you should save the file under a name that's different from the default name. Keep 
the .BAS file extension, however. The .BAS filename extension is usually reserved in Visual Basic for the general purpose external 
module files that you'll write and use. Even though CONSTANT.TXT is an external module file that breaks the .BAS file-naming 
rules, CONSTANT.TXT is an external module file.

<BR>

<P>The Project window for each application reflects which form file and module files (as well as CONSTANT.TXT if you use it) that each application requires. When you create a module, you're creating a 
stand-alone file on the disk that more than one 
application can use as long as you add that module to the applications' Project windows.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><B>Note: </B>Remember that the Project window 
doesn't hold files. The Project window holds only an application's list of needed files. You'll have to ensure that you distribute your Visual Basic applications with all files listed in each 
application's Project window (described in the .MAK file) if 
you write and distribute your Visual Basic applications to others.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>Suppose that you wrote several subroutine procedures that printed your company's name and address, calculated city sales 
taxes for sales in all of your division's 20 regions, and made a backup of data files if the date hits the first of the month. You 
may find that, although you originally wrote these procedures for a general ledger system that you were writing, you need 
those same procedures in other programs. You can open a new module from within the general ledger application's Code window, and cut 
and paste those procedures from the general ledger application to the new module. If you then saved the module under the 
name MYPROC.BAS, the general ledger application would be able to call that module's procedures (owing to the fact that Visual Basic 
added the module to the Project window when you first created the module), as well as <I>any other application to which you 
selected File Add and added the MYPROC.BAS module to.</I>

<BR>

<P>All programs automatically contain a form module. The module that you work in, using the Code window, that always displays when you open a form's or control's event procedure, is the form 
module. Additional modules that you add to the application, as 
well as the module supplied in CONSTANT.TXT, are sometimes called <I>non-form modules</I>.

<BR>

<P><FONT COLOR="#FF8000"><B><I>Review: </I></B></FONT>Over time, you'll create module files 
when you run across useful procedures that you might need elsewhere. You can have as many modules on your disk as you want and add any or all of them to subsequent 
applications that you write. In a way, you're then building new applications faster by 
reusing code (through the Call statement) that you wrote for other applications and stored in the general-purpose modules.

<BR>

<BR>

<A NAME="E68E116"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Functions 
Procedures</B></FONT></CENTER></H3>

<BR>

<P><FONT COLOR="#FF8000"><B><I>Concept: </I></B></FONT>As with the built-in functions, you can write your own general-purpose function procedures, often just called <I>functions</I>, that aren't tied to specific 
events. You can call these functions from 
your Visual Basic application. You can place these functions in their own external code modules or add them to an application's Code window. Function procedures work a lot like subroutine procedures; you can call 
them from elsewhere in the program. Unlike 
subroutine procedures, however, function procedures return values.

<BR>

<P>You can write your own function procedures to augment the built-in procedures supplied by Visual Basic. If you run across a needed 
calculation that converts a needed measurement, and you feel that you'll need that same conversion several places in your 
program, add that code to a function procedure. The function will be able to make the calculation and return the answer for the 
calculation to the calling routine.

<BR>

<P>As explained in the previous lesson, &quot;Functions and Dates,&quot; when you call built-in functions, you must do something with the return value. You can't code the Int() function on a line by itself like 
this:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">Int(Amount) ' Invalid!</FONT></PRE>

<P>Int(Amount) will return the amount converted to an integer, and you must do something with the returned integer. Therefore, you'll usually assign the return value like 
this:

<BR>

<BR>

<PRE>