MS-Access / Getting Started

---

Creating custom events

Events must be declared within a class module. Although an event declaration may occur anywhere within a VBA module, it only makes sense to position event declarations near the top of the module where they're easily seen by other developers. An event declaration is actually quite simple:

Public Event InvalidSupplierID()

That's all there is to an event declaration. The Public keyword is needed, of course, to expose the event to the class's consumers. In effect, the Public keyword adds the event to the class's interface. The Event keyword, of course, specifies that the declaration's identifier - InvalidSupplierID - is an event and should be managed by VBA's class module hosting mechanism.

You might recall that I've asserted that class modules were special in a number of regards. Events are clearly one of the special characteristics of VBA class modules.

A quick look through the Object Browser at the class module shows that the class's interface does, indeed, include the InvalidSupplierID event.

You'll notice a couple other events - InsufficientStockAvailable and ProductSold - in the Product class module. I've added the other events in exactly the same manner as the InvalidSupplierID event. An event declaration is all that's required to add an event to a class's interface. The class module never even has to trigger an event shown in the Object Browser.

Raising events

An event that is never invoked by a class module's code isn't much use to anybody. Events are typically triggered (or raised) whenever circumstances indicate that the consumer should be notified.

Raising an event requires a single line of code:

RaiseEvent <EventName>(<Arguments>)

Event arguments in the "Passing data through events" section, later in this tutorial. In the meantime, take a look at raising the InvalidSupplierID event from the SupplierName Property Get:

Public Property Get SupplierName() As String
  Dim varTemp As Variant
  If m_SupplierID <= 0 Then
    RaiseEvent InvalidSupplierID()
    Exit Property
  End If
  varTemp = DLookup("CompanyName", "Suppliers", _
    "SupplierID = " & m_SupplierID)
  If Not IsNull(varTemp) Then
    SupplierName = CStr(varTemp)
  Else
    RaiseEvent InvalidSupplierID()
  End If
End Property

The SupplierName property raises the InvalidSupplierID under two different situations: when the SupplierID is zero or a negative number, and when the DLookup function fails to locate a record in the Suppliers table.

There is no requirement that consumer code respond to events raised by class modules. In fact, events are very often ignored in application code. You've ever written code for every single event raised by an Access TextBox control, and custom events raised from class modules are no different.

But, again, that's one of the nice things about object-oriented programming: You can add as many events as needed by your classes. Consumer code working with your classes can ignore irrelevant events and trap only those events that are important to the application.