Difference between revisions of "Visual Basic Modules and Procedures"
(→Visual Basic Code Procedures) |
(→Defining Visual Basic Subroutines) |
||
Line 36: | Line 36: | ||
== Defining Visual Basic Subroutines == | == Defining Visual Basic Subroutines == | ||
+ | |||
+ | Subroutines are declared inside Visual Basic Modules. Our newly created module in Visual Studio contains the following: | ||
+ | |||
+ | <pre> | ||
+ | Module Math | ||
+ | |||
+ | End Module | ||
+ | </pre> | ||
+ | |||
+ | We are now going to add a subroutine called ''DisplayResult'' to this module. For syntax for a Visual Basic subroutine is as follows: | ||
+ | |||
+ | <tt>Public Sub DisplayResult()</tt><br> | ||
+ | |||
+ | The ''Public'' keyword indicates that this subroutine is accessible from Visual Basic code residing in other modules. The ''Sub'' keyword indicates that this is a Subroutine (as opposed to a Function) and as such, does not return a value on completion. Finally, the name of the Subroutine is provided. The parentheses are used to hold any parameters which may be passed through to the Subroutine when it is called. | ||
== Defining Visual Basic Functions == | == Defining Visual Basic Functions == |
Revision as of 15:16, 31 July 2007
A key part of developing applications using Visual Basic is ensuring that the code is carefully structured. This involves segmenting the code into projects, modules and procedures so that it is easy to understand and maintain.
A complete Visual Basic application is typically contained in a single project. Within a project, code is placed in separate code files called modules, and within each module, the Visual Basic code is further separated into self contained and re-usable procedures.
The topic of projects was covered in Creating a New Visual Basic Project. In this chapter we will look in detail at Visual Basic modules and procedures.
Visual Basic Code Modules
Visual Basic application source code is structured into module files with .vb suffix. By default, Visual Studio creates a separate module file for each form in an application containing the code to construct the form. For example, the code to create a form called Form1 will be placed in a module file named Form1.Designer.vb. Similarly, any code that has been defined by the developer to handle events from comtrols in the form will be placed by Visual Studio into a module file called Form1.vb.
When writing additional Visual Basic for an application, the code should ideally be logically grouped to together with other source code in a module file. When we say logically grouped we mean that the code should be grouped with other code of a similar nature. For example, code to work with files might be placed in a module called FileIO.vb, while mathematical procedures might all reside in a file name Math.vb. The idea is to ensure Visual Basic code is placed in a file where it make sense for it to be located. This will differ between applications, but it is worth investing the time to ensure code is well structured as doing so makes subsequent maintenance of the code by you or other developers much easier.
We mentioned previously that Visual Studio places the code to construct each form in separate module files. We now need to learn how to create a new module in a project to contain our own Visual Basic code. Begin by creating a new Windows Application project in Visual Studio called vbModules. Once the new project has been opened and the first form is visible, select Add Module... from the Project menu. The Add Item window will appear with the Module item pre-selected:
Name the new module Math.vb and click the Add button. The new module will be added to the project and a new tab labeled Math.vb for accessing the module code appears in the design area:
Now that we have added a new module to our project the next step is to add Visual Basic code to that module. Before we can do that, however, we need to learn about Visual Basic procedures.
Visual Basic Code Procedures
Visual Basic procedures provide a way to break up code into logical and re-usable sections that can be called from other sections of Visual Basic code. For example, you might have a section of Visual Basic code which calculates the interest due on a loan. It is also possible that you need to perform this calculation from a number of different places in your application code. Rather than duplicating the code to perform this task at each code location where it is needed, it is more efficient to place the calculation code in a procedure, and then call that procedure each time it is needed.
Visual Basic provides two types of procedures:
- functions - Functions are procedures which perform a task and return a value when completed.
- subroutines - Subroutines are procedures which perform a task but return no value when completed.
It is especially useful to be able to return values from functions. For example, the function may need to return the result of the task it performed (perhaps the result of a calculation). A function might also return a True or False value to indicate when the task was performed successfully. The Visual Basic code which called the function then then act based on the returned value.
In the case of both subroutines and functions, values (known as parameters) may optionally be passed into the procedure.
Defining Visual Basic Subroutines
Subroutines are declared inside Visual Basic Modules. Our newly created module in Visual Studio contains the following:
Module Math End Module
We are now going to add a subroutine called DisplayResult to this module. For syntax for a Visual Basic subroutine is as follows:
Public Sub DisplayResult()
The Public keyword indicates that this subroutine is accessible from Visual Basic code residing in other modules. The Sub keyword indicates that this is a Subroutine (as opposed to a Function) and as such, does not return a value on completion. Finally, the name of the Subroutine is provided. The parentheses are used to hold any parameters which may be passed through to the Subroutine when it is called.