Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (5.72 MB, 490 trang )
Note that the Project Explorer has a treelike structure, similar to the Windows Explorer's folders
pane (the left-hand pane). Each entry in the Project Explorer is called a node. The top nodes, of
which there are two in Figure 3-2, represent the currently open Excel VBA projects (hence the
name Project Explorer). The view of each project can be expanded or contracted by clicking on
the small boxes (just as with Windows Explorer). Note that there is one project for each currently
open Excel workbook.
3.1.1 Project Names
Each project has a name, which the programmer can choose. The default name for a project is
VBAProject. The top node for each project is labeled:
where ProjectName is the name of the project and WorkbookName is the name of the Excel
3.1.2 Project Contents
At the level immediately below the top (project) level, as Figure 3-2 shows, there are nodes named:
Microsoft Excel Objects
Under the Microsoft Excel Objects node, there is a node for each worksheet and chartsheet in the
workbook, as well as a special node called ThisWorkbook, which represents the workbook itself.
These nodes provide access to the code windows for each of these objects, where we can write our
Under the Forms node, there is a node for each form in the project. Forms are also called
UserForms or custom dialog boxes. We will discuss UserForms later in this chapter.
Under the Modules node, there is a node for each code module in the project. Code modules are
also called standard modules. We will discuss modules later in this chapter.
Under the Classes node, there is a node for each class module in the project. We will discuss
classes later in this chapter.
The main purpose of the Project Explorer is to allow us to navigate around the project.
Worksheets and UserForms have two components—a visible component (a worksheet or dialog)
and a code component. By right-clicking on a worksheet or UserForm node, we can choose to
view the object itself or the code component for that object. Standard modules and class modules
have only a code component, which we can view by double-clicking on the corresponding node.
Let us take a closer look at the various components of an Excel project.
220.127.116.11 The ThisWorkbook object
Under each node in the Project Explorer labeled Microsoft Excel Objects is a node labeled
ThisWorkbook. This node represents the project's workbook, along with the code component (also
called a code module) that stores event code for the workbook. (We can also place independent
procedures in the code component of a workbook module, but these are generally placed in a
standard module, discussed later in this chapter.)
Simply put, the purpose of events is to allow the VBA programmer to write code that will execute
whenever one of these events fires. Excel recognizes 19 events related to workbooks. We will
discuss these events in Chapter 11; you can take a quick peek at this chapter now if you are
curious. Some examples:
The Open event, which occurs when the workbook is opened.
The BeforeClose event, which occurs just before the workbook is closed.
The NewSheet event, which occurs when a new worksheet is added to the workbook.
The BeforePrint event, which occurs just before the workbook or anything in it is printed.
18.104.22.168 Sheet objects
Under each Microsoft Excel Objects node in the Project Explorer is a node for each sheet. (A
sheet is a worksheet or a chartsheet.) Each sheet node represents a worksheet or chartsheet's
visible component, along with the code component (also called a code module) that stores event
code for the sheet. We can also place independent procedures in the code component of a sheet
module, but these are generally placed in a standard module, discussed next.
Excel recognizes 7 events related to worksheets and 13 events related to chartsheets. We will
discuss these events in Chapter 11.
22.214.171.124 Standard modules
A module, also more clearly referred to as a standard module, is a code module that contains
general procedures (functions and subroutines). These procedures may be macros designed to be
run by the user, or they may be support programs used by other programs. (Remember our
discussion of modular programming.)
126.96.36.199 Class modules
Class modules are code modules that contain code related to custom objects. As we will see, the
Excel object model has a great many built-in objects (almost 200), such as workbook objects,
worksheet objects, chart objects, font objects, and so on. It is also possible to create custom
objects and endow them with various properties. To do so, we would place the appropriate code
within a class module.
However, since creating custom objects is beyond the scope of this book, we will not be using
class modules. (For an introduction to object-oriented programming using VB, allow me to
suggest my book, Concepts of Object-Oriented Programming with Visual Basic, published by
Springer-Verlag, New York.)
188.8.131.52 UserForm objects
As you no doubt know, Excel contains a great many built-in dialog boxes. It is also possible to
create custom dialog boxes, also called forms or UserForms. This is done by creating UserForm
objects. Figure 3-3 shows the design environment for the Select Special UserForm that we
mentioned in Chapter 1.
Figure 3-3. A UserForm dialog box
The large window on the upper-center in Figure 3-3 contains the custom dialog box (named
dlgSelectSpecial) in its design mode. There is a floating Toolbox window on the right that
contains icons for various Windows controls.
To place a control on the dialog box, simply click on the icon in the Toolbox and then drag and
size a rectangle on the dialog box. This rectangle is replaced by the control of the same size as the
rectangle. The properties of the UserForm object or of any controls on the form can be changed by
selecting the object and making the changes in the Properties window, which we discuss in the
In addition to the form itself and its controls, a UserForm object contains code that the VBA
programmer writes in support of these objects. For instance, a command button has a Click event
that fires when the user clicks on the button. If we place such a button on the form, then we must
write the code that is run when the Click event fires; otherwise, clicking the button does nothing.
For instance, the following is the code for the Close button's Click event in Figure 3-3. Note that
the Name property of the command button has been set to cmdClose :
Private Sub cmdClose_Click()
All this code does is unload the form.
Along with event code for a form and its controls, we can also include support procedures within
the UserForm object.
Don't worry if all this seems rather vague now. We will devote an entire chapter to creating
custom dialog boxes (that is, UserForm objects) later in the book and see several real-life
examples throughout the book.
3.2 The Properties Window
The Properties window (see Figure 3-1) displays the properties of an object and allows us to
When a standard module is selected in the Project window, the only property that appears in the
Properties window is the module's name. However, when a workbook, sheet, or UserForm is
selected in the Projects window, many of the object's properties appear in the Properties window,
as shown in Figure 3-4.
The Properties window can be used to change some of the properties of the object while no code is
running—that is, at design time. Note, however, that some properties are read-only and cannot be
changed. While most properties can be changed either at design time or run time, some properties
can only be changed at design time and some can only be changed at run time. Run-time
properties generally do not appear in the Properties window.
Figure 3-4. The Properties window