Use this diagnostic workflow for an event procedure in an approved desktop Excel workbook. It addresses automatic event handling; the manually run macro guide covers a separate execution model.
Reproduce the right kind of change
This original fictional workbook has a sheet called Intake. A proposed event procedure watches B2:B20 and writes a reviewed status beside each changed value in column C. The actual status rule must be supplied by the workbook owner; changing how the event runs does not establish that rule.
| Action in a disposable workbook | Expected event behavior | Question for the code review |
|---|---|---|
| Type into B2 | Change receives a target containing B2 | Does the procedure use Target rather than ActiveCell? |
| Paste into B2:B4 | Target may contain all three cells | Does the procedure handle every relevant cell? |
| Edit D2 | Change occurs, but outside the watched range | Does it exit without touching C? |
| A formula already in B2 changes result during recalculation | Change does not fire for the recalculated result | Is the requested behavior actually a calculation-event problem? |
Microsoft's Worksheet.Change reference, checked October 24, 2026, establishes the multi-cell target and recalculation distinction. Do not describe a nonfiring Change handler as broken until you know which action occurred.
Inspect range intersection and event reentry
An event handler belongs in the relevant worksheet's code module. A similarly named procedure pasted into a standard module does not become that worksheet's automatic handler.
Ask the model to explain Intersect(Target, Me.Range("B2:B20")). The intersection identifies affected cells inside the watched range, including the in-range part of a larger paste. A guard that exits whenever Target has more than one cell intentionally skips pasted blocks; confirm whether that matches the requirement.
Writing to column C can trigger another Change event. Code commonly disables events around its writes. Application.EnableEvents is an application property, so leaving it disabled after an error can affect other event procedures in that Excel session.
Require cleanup on both the successful and error paths. The handler should save the prior state, disable events only when it is about to write, and restore the saved state before leaving. Do not let a blanket On Error Resume Next conceal a failed write or skip that restoration.
This is a code-review requirement, not an instruction to paste an unreviewed event handler into a working workbook. Protection, merged cells, error values and the desired handling of deleted values may change the correct implementation.
Copy an event-specific diagnostic prompt
Review this desktop Excel Worksheet.Change procedure before rewriting.
Excel version/OS, workbook copy and worksheet module: [ENTER]
Complete event code and called procedures: [PASTE]
Watched range and permitted output cells: [ENTER]
Exact action: typed edit, paste, deletion, external link or recalculation?
Actual Target address/count if observed: [ENTER OR UNKNOWN]
Expected status rule, actual result and exact runtime error: [PASTE]
Protection, merged cells and formula/error-value rules: [ENTER]
Trace whether this action should raise Change. Check module placement,
Target versus ActiveCell, range intersection and multi-cell behavior.
Identify writes that can raise another event. Trace EnableEvents on
success, each early exit and each error path; restore its prior state.
Separate a wrong event choice from a range or business-rule defect.
Propose only the smallest relevant change and disposable-workbook checks.
Do not invent an Excel run, alter security settings or suppress errors.
OpenAI's prompting guidance supports giving the context that changes the answer. Here, the user's exact action and complete event code matter more than a description such as "the macro sometimes stops."
Test the failure path as well as one successful edit
In the disposable copy, try a single-cell edit, a multi-cell paste, an out-of-range edit and the stated recalculation case. Record the actual affected cells. Verify that protected or otherwise rejected writes report their failure and leave the event state restored. Do not create a deliberate error in an operational workbook.
Keep those observations with the accepted handler and its watched-range rule. If the event still fails, bring the exact error and smallest reproduction to the debugging workflow; repeated whole-module rewrites make it harder to see which assumption was wrong.