A VB project consists of one or more modules. Technically, a module is any file that contains VB code, and can either be a form module, a standard module, or a class module. When the term "module" is used by itself, it refers to a standard module. I will use the term "code module" to refer to any of the three types. Although I am mentioning class modules in this section, the subject of how to use them will be treated separately in a later section. Classes were introduced in VB4 in an effort to make VB more of an object-oriented language; forms and standard modules have been around from "day one".
In the VB environment, code modules are given default names such as "Form1", "Form2", "Module1", "Class1", etc.; but you can rename these with more descriptive names. However, these files must also be saved in the Windows file system: form modules have an extension of .frm, standard modules have an extension of .bas, and class modules have an extension of .cls. When you save a form file, any graphical elements on that form (such as icons or bitmaps) are automatically saved in a file with the extension .frx. The entire project must also be saved in a file with a .vbp extension (this file basically contains a list of all of the files that make up the project). As you saw in Part 1, VB will also automatically create a .vbw file. If the SourceSafe is installed on your machine, an .scc file will also be generated.
When you start a new project, VB automatically gives you one form to start out with. This is a good starting point; sometimes it is all you need. (Your early programs will just involve one form.) You can add as many other forms, standard modules, and classes as you need to the project. You can also remove code modules from the project. When you have more than one code module in a project, you must specify a "Startup object", which is done via the Project menu, Properties item. The startup object tells VB which form or standard module is to have its code run first (if a standard module is the startup object, it must contain a public subroutine called "Main", and "Sub Main" is specified for the Startup object).
Code modules consist of one or more procedures, which are Subs or Functions. Procedures are either event procedures or programmer-defined procedures. Event procedures contain code that you want to execute in response to an event (such as when a user clicks a command button with the mouse); programmer-defined procedures are general procedures, called under your control (i.e., not in response a particular external event). Forms can contain both event and programmer-defined procedures; standard modules can only contain programmer-defined procedures.
A Sub or Function procedure can be either public or private in scope. A public procedure can be referenced by any other module in the project; a private procedure can only be referenced within the module in which it is defined. Event procedures, which can only occur in forms, are private by default. In general, all form procedures should be private (unless there is a specific reason to make them public). Public procedures in forms, when called by other modules, must be referred to with "qualifying" syntax: for example, to call public sub "A" in Form1 from Module1, I couldn't just say "Call A" – I would have to say "Call Form1.A". Public procedures should be reserved for standard modules; standard modules are typically where you place code that is shared by the various modules in the project. References to public procedures of standard modules need not be qualified.
The figure below attempts to highlight some of the concepts discussed above:
PROJECT |
(Form1)Private Sub A() Call B 'OK – B is in same module Call C 'OK – C is Public in MODULE1 Call D 'Error – D is Private to MODULE1 End Sub
Public Sub B() Call A 'OK – A is in same module Call C 'OK – C is Public in MODULE1 Call D 'Error – D is Private to MODULE1 End Sub |
(Module1)Public Sub C() Call Form1.A 'Error – A is Private to Form1 Call Form1.B 'OK – B is Public in Form1 Call D 'OK – D is in same module End Sub
Private Sub D() Call Form1.A 'Error – A is Private to Form1 Call Form1.B 'OK – B is Public in Form1 Call C 'OK – C is in same module End Sub |
Note from the table above that a Sub procedure consists of a procedure header in the format:
[Public | Private] Sub ProcedureName()
followed by the code that makes up that procedure, followed by the statement End Sub. As you will discover later, the procedure header can get more complicated than this. As you saw in Part 1, when you want to create an event procedure, VB will automatically generate the "stub" for the event procedure (it will generate the procedure header and the End Sub statement, and you just fill in the code in-between). These event procedures are always Private in scope. When you create a programmer-defined procedure, if you omit the word Private or Public, the default is Public.
Note: Lines of code beginning with an apostrophe (') are regarded as comments are ignored and not executed by VB. Comments can also occur in the middle of a line (as in the previous example). Once VB sees an apostrophe in a line, the remainder of that line is ignored. (An exception to this is when the apostrophe is part of a quoted string.)