Events in Excel VBA

Analogy categoryAnalogies

The Event-Driven Model in Excel

Beyond macros that a user runs on demand, Excel can run code automatically in response to things that happen — a cell being edited, a sheet being activated, or a workbook being opened. These triggers are events, and the procedures that respond are event handlers. Handlers live in specific object modules, not standard modules: workbook events go in the ThisWorkbook module, and worksheet events go in that sheet's own module. You select the object and event from the two dropdowns at the top of the code window, which generates a correctly named stub such as Private Sub Worksheet_Change. The name and signature must match exactly or the handler never fires.

🏏

Cricket analogy: An event handler is like a fielder positioned specifically for a hook shot — they don't act until that exact stroke happens, then they spring automatically, just as Worksheet_Change fires only on an edit.

Workbook and Worksheet Events

The most-used worksheet events are Worksheet_Change, which fires after a user edits a cell and passes the edited Target range, and Worksheet_SelectionChange, which fires whenever the selection moves. Workbook-level events include Workbook_Open (runs when the file opens, great for setup), Workbook_BeforeClose (which offers a Cancel argument to abort closing), and Workbook_BeforeSave. Many events pass arguments you use to make decisions — Worksheet_Change gives you Target so you can check Intersect(Target, Range("B:B")) to react only to edits in column B, and BeforeClose gives you a Cancel Boolean you set to True to stop the close.

🏏

Cricket analogy: Worksheet_Change passing Target is like a third-umpire review that tells you exactly which delivery is under scrutiny, so you judge only that ball rather than the whole over.

vba

' --- In a worksheet's code module ---
Private Sub Worksheet_Change(ByVal Target As Range)
    ' Only react to edits in column B (Amount)
    If Intersect(Target, Me.Range("B:B")) Is Nothing Then Exit Sub

    Application.EnableEvents = False           ' prevent re-triggering
    On Error GoTo CleanUp

    ' Stamp the edit time in column C
    Me.Cells(Target.Row, 3).Value = Now

CleanUp:
    Application.EnableEvents = True
End Sub

' --- In the ThisWorkbook module ---
Private Sub Workbook_Open()
    MsgBox "Welcome! Data as of " & Format(Date, "mmm d, yyyy"), vbInformation
End Sub

If an event handler writes to cells, it can trigger itself again (a Worksheet_Change that edits a cell fires Worksheet_Change), causing infinite recursion. Guard against this by setting Application.EnableEvents = False before writing and restoring it to True afterward — always in an error handler, because if code errors out with events disabled, no future events will fire until you re-enable them.

Application Events and the WithEvents Keyword

Worksheet and workbook events are limited to their own object, but Application-level events fire for every open workbook — for example App_WorkbookBeforePrint or App_SheetChange across all sheets. These are not available by default; you declare an object variable using WithEvents inside a class module (Dim WithEvents App As Application), then assign Set App = Application, usually in Workbook_Open. Once hooked, the class module exposes the full set of application events. This pattern is also how you respond to events from objects that have no built-in module, such as a specific chart or a command bar.

🏏

Cricket analogy: Application events firing for every workbook are like a broadcast umpire whose decisions apply to all matches in the tournament at once, not just one ground.

Application.EnableEvents only affects Excel's own object events; it does not stop WithEvents handlers on non-Excel objects, nor does it persist — Excel resets EnableEvents to True the next time it starts. So a handler that leaves it False after an unhandled error only suppresses events for the rest of the current session, but that is enough to break your workbook's automation until restart.

Excel is event-driven: code can run automatically in response to edits, selections, opens, saves, and more.
Event handlers live in object modules — ThisWorkbook for workbook events, the sheet's module for worksheet events.
Worksheet_Change passes the edited Target; use Intersect to react only to specific ranges.
Workbook_Open runs at file open; Workbook_BeforeClose and BeforeSave expose a Cancel argument to abort the action.
Set Application.EnableEvents = False before a handler writes cells to prevent recursive re-triggering, and restore it in an error handler.
Application-level events fire across all workbooks and require declaring an object WithEvents in a class module.
WithEvents is also how you handle events from objects lacking their own code module, like specific charts.