VBA Worksheet_BeforeRightClick in Excel — Replace the Right-Click Menu (and Why Disabling It Isn't Security)

TL;DR — Worksheet_BeforeRightClick is an event Excel fires the instant you right-click a cell — before the context menu appears. It hands you Target (the cell) and Cancel. Set Cancel = True and Excel's built-in right-click menu is suppressed, so you can put your menu — or a direct action — in its place. The trap almost everyone hits is scope: an unconditional Cancel = True disables Copy, Paste and Insert for the whole sheet, so guard it with Intersect. And know this up front — disabling right-click is a UX choice, not a security one.

' Lives in the sheet's module (double-click "Sheet1" under Microsoft Excel Objects).
Private Sub Worksheet_BeforeRightClick(ByVal Target As Range, Cancel As Boolean)
    ' Only hijack right-clicks inside the Status column; leave the rest of the sheet alone.
    If Intersect(Target, Me.Range("C2:C100")) Is Nothing Then Exit Sub

    Cancel = True                       ' <-- suppress the built-in context menu
    Target.Value = Date                 ' right-click stamps today's date instead
End Sub

Most macros wait for a button. Worksheet_BeforeRightClick waits for a gesture — a right-click on a cell — and it runs before Excel does the thing a right-click normally does: show the context menu. That "before" is the opening you need. You can suppress the default menu and substitute your own, turn a right-click into a one-gesture command, or add a couple of custom items to what Excel already offers. It's also the event people reach for to "lock down" a sheet — and that's where the most important lesson lives.

What you'll learn

• The mental model — a right-click is a request for a menu, and you get to answer it
• The rule that matters most — Cancel = True is what actually suppresses the built-in menu
• Why scoping with Intersect is not optional — the unscoped version cripples the sheet
• The judgment call — disabling right-click is UX, never protection
• Sheet-level vs workbook-level, and where the code has to live

The mental model: a request for a menu you get to answer

A right-click already means something to Excel: "show me the context menu for this cell." When you write Worksheet_BeforeRightClick, Excel calls your code first and waits — the menu hasn't appeared yet. You get Target, the cell that was right-clicked, and Cancel, a Boolean passed by reference. Leave Cancel alone and Excel shows its normal menu after your code runs. Set Cancel = True and it doesn't — you've answered the request yourself, and now the right-click means whatever your handler made it mean.

That reframes the event. It isn't "notify me on right-click." It's "let me decide what a right-click offers here." You can run an action directly (stamp a date, mark a row, open a detail form), or pop your own menu built with CommandBars. Either way the built-in menu only disappears when you say so, with Cancel = True. And like every event in this family, this one lives in the worksheet's own code module — not a standard Module, and not ThisWorkbook.

The rule that matters most: Cancel = True suppresses the built-in menu

Here is the mistake. You want a right-click to run your own command, so you write the action and stop:

Private Sub Worksheet_BeforeRightClick(ByVal Target As Range, Cancel As Boolean)
    Target.Value = Date        ' stamps the date... and Excel's menu still pops up
End Sub

The date lands — and then the full context menu appears anyway, because nothing set Cancel. The user now has both your action and Excel's Cut/Copy/Paste menu on top of it. The rule: Cancel = True is the line that replaces the menu. Set it whenever your handler is meant to be the right-click's response:

Private Sub Worksheet_BeforeRightClick(ByVal Target As Range, Cancel As Boolean)
    Cancel = True              ' the built-in menu never shows
    Target.Value = Date        ' your command is the whole interaction
End Sub

If instead you want to add an item rather than replace the menu, leave Cancel alone and add your control to Application.CommandBars("Cell") — Excel shows its menu with your extra item on it. Suppress (with Cancel = True) when you're replacing; extend the Cell CommandBar when you're adding.

The rule that keeps the sheet usable: scope it with Intersect

This event punishes an unscoped handler harder than any other. If your code runs on every right-click and sets Cancel = True, you have removed the entire right-click menu from the whole sheet — no Copy, no Paste, no Insert, no Filter, no Format Cells, anywhere. You didn't customise the sheet; you broke it.

Scope to the cells that are meant to have custom behaviour, and let every other cell keep its normal menu:

Private Sub Worksheet_BeforeRightClick(ByVal Target As Range, Cancel As Boolean)
    ' Custom behaviour only in the Status column; normal menu everywhere else.
    If Intersect(Target, Me.Range("C2:C100")) Is Nothing Then Exit Sub

    Cancel = True
    Target.Value = Date
End Sub

Intersect(Target, Me.Range("C2:C100")) returns Nothing outside your target range, so Exit Sub hands control back to Excel and the built-in menu appears as usual. This is the same Intersect guard that keeps a Worksheet_Change handler targeted — here it's the difference between a helpful sheet and an unusable one.

The judgment call: disabling right-click is UX, not security

People find this event by searching "how do I disable right-click to protect my sheet." So say it plainly: a Cancel = True right-click block protects nothing. It only stops one input path — the mouse menu. Everything else still works: Ctrl+C and Ctrl+V, the ribbon, the Name Box, another macro, and — the one that ends the argument — opening the file with macros disabled, which turns your entire event off. If a determined user or a bad actor is your threat model, BeforeRightClick does not touch it.

What the event is good for is shaping the interaction: hiding a menu that's irrelevant in a data-entry area, replacing it with two commands that actually fit the task, or stamping a value with a gesture. Use it to make the right thing easy, not to make the wrong thing impossible. If you need real protection, that's sheet protection, workbook structure protection, and not trusting a client-side event — a different tool entirely.

The distinction that decides where the code goes: sheet vs workbook

Worksheet_BeforeRightClick is a per-sheet event — it lives in one worksheet's module and only fires on that sheet. To apply the same behaviour everywhere, use the workbook-level twin Workbook_SheetBeforeRightClick in ThisWorkbook, which adds a first argument, Sh, for the sheet involved:

' In ThisWorkbook - fires for a right-click on ANY sheet.
Private Sub Workbook_SheetBeforeRightClick(ByVal Sh As Object, ByVal Target As Range, Cancel As Boolean)
    If Sh.Name <> "Log" Then Exit Sub
    If Intersect(Target, Sh.Range("C2:C100")) Is Nothing Then Exit Sub
    Cancel = True
    Target.Value = Date
End Sub

Same choice you make with Worksheet_Activate vs Workbook_SheetActivate: one sheet → the sheet's module; any sheet → the workbook module with the Sh argument. And it pairs naturally with its gesture sibling Worksheet_BeforeDoubleClick, which intercepts a double-click with the same Target plus Cancel shape.

How ExcelMaster helps

A right-click handler is three decisions that are easy to get wrong: the Intersect guard that keeps Copy and Paste alive off your target range, the Cancel = True that actually suppresses the menu, and the honest judgment about what a block does and doesn't protect.

ExcelMaster lets you describe the behaviour instead. Say "right-clicking a cell in the Status column should stamp today's date and not show the normal menu, but leave the rest of the sheet alone," and it writes a Worksheet_BeforeRightClick in the right module, scopes it with Intersect, and sets Cancel. You keep the workbook and the code; you skip the trial-and-error — and you get told, not sold, on what it protects.

Frequently asked questions

How do I run a macro on right-click in Excel?

Put a Worksheet_BeforeRightClick procedure in the sheet's code module: Private Sub Worksheet_BeforeRightClick(ByVal Target As Range, Cancel As Boolean). Excel calls it when a cell on that sheet is right-clicked and passes Target. Add your action, and set Cancel = True if you want to replace the built-in menu.

How do I disable the right-click menu in VBA?

Set Cancel = True inside Worksheet_BeforeRightClick. That suppresses the context menu. Scope it with Intersect unless you truly want it gone across the whole sheet — an unconditional block removes Copy, Paste and Insert everywhere. Note it only blocks the mouse menu; it is not a security control.

Does disabling right-click protect my data?

No. It only removes one input path. Ctrl+C/Ctrl+V, the ribbon, other macros, and opening the file with macros disabled all bypass it. Use BeforeRightClick to streamline the interaction, and use sheet/workbook protection for actual protection.

How do I add a custom item to the right-click menu instead of replacing it?

Leave Cancel unset and add a control to Application.CommandBars("Cell") — Excel shows its normal menu with your extra item. Set Cancel = True only when you want to replace the menu rather than extend it.

Where does Worksheet_BeforeRightClick code go?

In the specific worksheet's code module — double-click the sheet under "Microsoft Excel Objects" in the Project Explorer. For a right-click on any sheet, use Workbook_SheetBeforeRightClick in ThisWorkbook instead. It does not fire from a standard Module, and macros must be enabled.

Tested in

Tested in: Excel 365 (Windows 11), VBA 7.1 — last verified 2026-08-06.

Related guides: VBA Worksheet_BeforeDoubleClick · VBA Workbook_BeforePrint · VBA Worksheet_Change · VBA Worksheet_Activate & Deactivate · VBA Range