Microsoft Access 2010 Bible

Chapter 28: Object-Oriented Programming with VBA

999

FIGURE 28.12

The Class_Terminate event procedure passes control back to the consumer code when it ends.

Consumer Code

Set objProduct = Nothing

MsgBox “Done”

A

Product Class

Private Sub Class_Terminate

End Sub

m_Recordset.Close

Set m_Recordset = Nothing

m_Database.Close

Set m_Database = Nothing

B

C

D

Just as with the Class_Initialize event procedure, the sequence of Class_Terminate’s

execution is important:

l (^) In A, the object is set to Nothing, or goes out of scope. Before the statement causing
these states executes, control is passed to Class_Terminate.
l (^) Just as you saw with Class_Initialize, notice that Class_Terminate (B) is a pri-
vate subroutine. It’s owned by the class and executes independently of the consumer code.
No arguments are passed to Class_Terminate.
l Execution is passed back to the consumer code at C, when Class_Terminate ends.
l (^) In D, execution recommences in the consumer code at the statement following the object’s
dismissal.
Adding Events to Class Modules
Everyone is familiar with the interfaces supported by the objects built into Microsoft Access. A
TextBox object, for example, supports ForeColor and BackColor as properties. The DoCmd
object provides a wide variety of methods (such as OpenForm) that perform a number of essential
actions in Access applications.
Beginning with Access 2000, developers have been able to add events to the class modules in their
applications. (Although Access 97 supported class modules with properties and methods, Access
97 didn’t provide for custom events in class modules.) Adding events to your class modules is an
excellent way to enhance and strengthen the object-oriented elements you add to your
applications.