1. Trang chủ >
  2. Công Nghệ Thông Tin >
  3. Quản trị mạng >

Figure 3-1. The Excel VBA IDE

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:

ProjectName (WorkbookName)

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. 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. 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. 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.) 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.) 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

next section.

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()

Unload Me

End Sub

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

change them.

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

17 ®


Xem Thêm
Tải bản đầy đủ (.pdf) (490 trang)