Vba excel события мыши

Once you’ve created a macro, you need a way to execute or call it. Otherwise, all of your work designing and coding the VBA application would’ve been in vain.

Within Excel, you have several different options for calling or running a VBA Sub procedure. In fact, in this Excel VBA tutorial alone, I explain 9 different ways in which you can execute a Sub procedure.

A very useful way of executing a macro is by telling Excel that a Sub procedure should be executed when a particular event occurs. As I explain below, knowing how to do this allows you to create VBA applications that are able to do things that would otherwise be impossible.

This blog post focuses on the topic of Excel VBA events. To be more precise:

In this tutorial, I provide all the information you need to understand what are Excel VBA events and how to start using them in your macros.

I also provide a complete list of Application events, workbook events, worksheet events, chart events, and non-object events. This Excel VBA Events Tutorial is accompanied by a Cheat Sheet with a shorter version of this list of VBA events. You can get immediate free access to this Cheat Sheet by subscribing to the Power Spreadsheets Newsletter.

The following table of contents lists the main topics I cover in this tutorial:

Let’s start by taking a look at…

What Are Excel VBA Events

In regular English, an event is something that happens.

You can, from a broad perspective, use the same definition for an event within Visual Basic for Applications. In other words, an Excel VBA event is something that happens while you’re working on Excel.

Events happen all the time while you’re working in Excel. As explained in both Excel Macros for Dummies and Excel 2016 Power Programming with VBA:

Everything that happens in Excel happens to an object through an event.

I provide a very detailed list of events below.

The concept of an Excel VBA event is relatively simple. Therefore, you might be wondering…

Why Are Excel VBA Events Useful

The main reason why you may find events useful is because you can create macros that are automatically executed when a certain event occurs. This allows you to, among other things:

• Add interactivity to your Excel workbooks.
• Improve user experience.
• Perform activities that would otherwise (without VBA events) be impossible.

The Sub procedures that are automatically executed when a particular event occurs are usually known as event-handler procedures. Note that event-handler procedures are always Sub procedures. You generally don’t handle events with Function procedures.

Now that you understand what is an Excel VBA event, and why it’s useful, let’s start to check out the…

Main Categories Of Excel VBA Events

Most Excel experts classify Excel VBA events on the basis of which is the object of the event. In other words, they take into consideration the VBA object where the event occurs.

On the basis of this criteria, you can classify events in the following categories:

• Application Events, which occur to the Excel Application itself.
• Workbook Events, which happen when something happens to a workbook.
• Worksheet Events, which are triggered whenever something happens to a worksheet.
• Chart Events, which occur when something happens to a chart.
• UserForm Events, which happen to a UserForm or an object within a UserForm.

  This VBA tutorial doesn’t cover the topic of UserForms or UserForm events. I may write about this in the future. If you want to receive an email whenever I publish new tutorials in Power Spreadsheets, please make sure to register for our Newsletter by entering your email address below:

• Non-object Events, which aren’t associated with a particular object. These events work different from the previous categories. In fact, you access these events through VBA methods of the Application object.

Before we dig deeper into the events themselves, let’s see…

How To Create Event-Handler Procedures

In certain respects, the process of creating an event-handler procedure is the same that you would follow when crafting regular Sub procedures.

However, there are 2 characteristics that are particular to event-handler procedures and have a material effect on the way you should proceed:

• Characteristic #1: As a general rule, event-handler procedures must be stored in the module that corresponds to the relevant object where the event happens.

  This is very important: Event-handler procedures generally don’t go in a standard module. As explained in Excel VBA Programming for Dummies, if you store an event-handler procedure in a standard module:

  #1: The procedure won’t be executed when the event occurs.

  #2: You won’t receive an error message.

  The exceptions to this rule are: (i) non-object events which go in a standard module, and (ii) Application and embedded Chart events which go in a Class Module.

  Even though you can only store event-handler procedures within certain modules, those event-handler procedures can still call other procedures that you store within other modules (including normal modules).

• Characteristic #2: The structure of the names of event-handler procedures are generally composed of 3 items:

  Item #1: The relevant object.

  Item #2: An underscore (_).

  Item #3: The name of the event that triggers the Sub procedure.

  Furthermore, several event-handler procedures have arguments passed to the procedure. The names of the arguments vary depending on the particular case. You can find several examples of event-handler procedures that use arguments below.

Fortunately, you can easily handle both of these characteristics by following the steps I describe below. In the words of Excel guru John Walkenbach (in Excel VBA Programming for Dummies):

Writing these event-handlers is relatively straightforward after you understand how the process works.

Let’s take a look at the basics of this process:

Step #1: Go To The Appropriate Module

As a general rule, event-handler procedures must be stored within a particular module. In the following sections, I explain:

• In which module should you store a particular event-handler procedure, depending on its characteristics.
• How can you get to (or create) that module.

The sections below aren’t applicable to the non-object events (OnTime and OnKey) which I explain below. In those cases, you can store the relevant procedures within a normal module.

In the case of Application, Workbook, Worksheet and Chart events (which are the bulk of what I cover in this blog post), the following are the 2 rules you must consider to determine where to store your VBA code:

• Rule #1: If you’re working with Workbook, Worksheet or Chart (for chart sheet) events, you use the code module of the corresponding object.
• Rule #2: If you want to work with Application or Chart (for embedded charts) events, you use a Class Module.

Let’s start by taking a look at rule #1. In other words, let’s see…

How To Go To An Object Code Module: Usual Process

In most cases, you can easily get to the Code module you want to go to in the following 2 simple steps:

Step #1: Go To The Visual Basic Editor.

First, you must go to the Visual Basic Editor. You can easily do this in either of the following ways:

• Select “Visual Basic” within the Developer Tab of the Ribbon.

  

• Use the keyboard shortcut “Alt + F11”.

Step #2: Display The Code Of The Appropriate Module

Once you’re within the environment of the Visual Basic Editor, go to the Project Window. This is window is usually located on the upper-left side of the screen.

Within the Project Window, each workbook or add-in that’s currently open appears as a separate project. In the screenshot above, there’s only 1 project (Book1.xlsx).

Each project may contain several nodes. Regardless of the number of nodes, focus on the Microsoft Excel Objects node.

The Microsoft Excel Objects node usually contains the following items:

• Each worksheet within the relevant workbook.

  You should use the appropriate Sheet module for event-handler procedures that refer to a particular worksheet (worksheet events).

  

• Each chart sheet within the workbook.

  Similar to worksheets, you use the relevant Chart module for event-handler procedures that refer to a certain chart sheet (chart events).

  

• The workbook itself.

  You use the ThisWorkbook module for event-handler procedures that deal with the workbook (workbook events).

  

For these purposes, each separate worksheet and chart sheet is a separate object. In order to display the code of the specific module you want to work with, you can do either of the following:

• Double-click on the object module.
• Right-click on the object module and select “View Code”.

  For example, the following image shows how it looks like when I ask the VBE to display the code within ThisWorkbook.

How To Go To A Worksheet Or Chart Sheet Code Module (Alternative)

In the case of sheets, you can also get to the relevant module in the following 2 easy steps:

• Step #1: Right-click on the relevant worksheet or chart sheet.

  

• Step #2: Select “View Code” within the context menu that Excel displays.

  

Now that you know how to get to the modules that correspond to workbooks, worksheets and chart sheets, let’s take a look at…

How To Create A Class Module For Dealing With Application Events

As I explain above, in order to work with Application and embedded Chart events, you must work with a Class Module. This section covers how to create a Class Module to work with Application events. The following section does the same thing for embedded Chart events.

In order to create a Class Module for purposes of dealing with Application events, you just need to follow these 7 easy steps:

• Step #1: Go to the Visual Basic Editor by following the explanation I provide above.
• Step #2: Insert a Class Module. You can do this by (i) right-clicking on the relevant VBA project within the Project Explorer window, (ii) selecting “Insert” and “Class Module”.

  

  Alternatively, you can insert a Class Module by going to the Insert menu of the VBE and selecting “Class Module”. If you want to work with keyboard shortcuts, you can use “Alt, I, C”.

  

• Step #3: Assign a new name to the Class Module you just created. You can easily do this by typing the name you want in the (Name) field within the Properties Window of the VBE.

  

  For this particular example, I name the module “applicationClassModule”.

  

• Step #4: Use the WithEvents keyword to declare a Public Application object. The basic form of this statement is as follows:
  

  Public WithEvents applicationObjectName As Application
  

  For these purposes, applicationObjectName is the name of the declared Application object. In the example below, I use the name “applicationObject”.

  

• Step #5: If you’ve not inserted a regular VBA module yet, do this. You can insert a module by (i) right-clicking on the appropriate VBA Project, and (ii) selecting to Insert a Module.

  

  Alternatively, you can select “Module” from within the Insert menu or use the keyboard shortcut “Alt, I, M”.

  

• Step #6: Declare a module-level object variable within the appropriate module. The module in which you declare the variable must be the one in which you store the Sub procedure to which I make reference in step #7 below.

  The purpose of this object variable is to refer to the Public Application object that you’ve declared in step #4 above. You can use a statement of the following form in order to do this declaration:

  Dim objectVariableName As New classModuleName

  For these purposes: (i) objectVariableName is the name you want to assign to the newly declared object variable, and (ii) classModuleName is the name of the Class Module you created in step #2 above. In the example below, classModuleName is “applicationClassModule” and objectVariableName “classApplication”. The variable is declared in a normal module.

  

• Step #7: Connect the object variable you declared in step #6 with the Application object you declared in step #4. You do this by executing a Sub procedure that uses the following Set statement to make the appropriate assignment:
  

  Set objectVariableName.applicationObjectName = Application

  For these purposes: (i) objectVariableName is the name you assigned to the object variable in step #6, (ii) applicationObjectName is the name you assigned to the Application object in step #4. In the following example, objectVariableName is “classApplication” and applicationObjectName is “applicationObject”.

  

  If this statement isn’t executed, the Application-level event-handler procedures won’t work appropriately.

  In the example above, I include the assignment statement within a macro stored in a regular VBA module. You can, however, include the Set statement is in the Workbook_Open Sub event-handler procedure. This procedure is triggered when the Workbook.Open event (the workbook is opened) occurs.

  

  If you change the module in which you store the procedure that connects the object variable and Application object, remember to adjust the location of the object variable declaration made in step #6 above. In other words, make the object variable declaration in the same module.

If you want to create a Class Module for purposes of working with Chart events, the process is substantially similar to that above. However, since there are a couple of differences, let’s take a closer look at…

How To Create A Class Module For Dealing With (Embedded) Chart Events

The process of creating a Class Module for purposes of working with Chart events for embedded charts, is very similar to the one I describe above for Application events. In fact, as you’ll notice below, all of the steps are either identical or materially the same.

You can use a Class Module for purposes of working with both embedded charts and chart sheets.

The 5 easy steps you must follow to create such a Class Module are as follows.

• Step #1: Follow steps #1, through #3 of the process I describe above for purposes of creating a Class Module. In other words:

  #1: Go to the Visual Basic Editor.

  #2: Create a Class Module.

  #3: Rename the Class Module.

  In this example, I create a Class Module named “embeddedChartClassModule”.

  

• Step #2: Declare a Public Chart object within the newly created Class Module by using the WithEvents keyword. In this particular case, the basic structure of the statement is as follows:
  

  Public WithEvents chartObjectName As Chart

  chartObjectName is the name you want to assign to the newly declared Chart object. In the example below, chartObjectName is “embeddedChartObject”.

  

• Step #3: If necessary, insert a regular VBA module, as I explain in step #5 of the process to create a Class Module to deal with Application events.
• Step #4: Declare a module-level object variable within the module in which you’ll store the Sub procedure to which I refer to in step #5 below.

  This object variable makes reference to the Public Chart object you declared in step #2 above. The basic form of the statement you can use for the declaration is pretty much the same as that in step #6 of the process to create a Class Module when working with Application events.

  Dim objectVariableName As New classModuleName

  objectVariableName is the name of the newly declared object variable. classModuleName is the name of the Class Module you created in step #1 above. In the following example, objectVariableName is “classEmbeddedChart”. classModuleName is “embeddedChartClassModule”, which is the name I assigned to the ClassModule in step #1.

  

  In this particular case, I’m using the same regular module as I used when explaining how to create a Class Module to deal with Application events. This may help you notice the similarities between both statements.

• Step #5: Connect the object variable you declared in step #4 and the Chart object you declared in step #2. You do this by executing a Sub procedure that uses the following Set statement to make an assignment:
  

  Set objectVariableName.chartObjectName = Chart

  objectVariableName is the name you assigned to the object variable in step #4 (classEmbeddedChart in the example below). chartObjectName is the name you assigned to the Chart object in step #2 (embeddedChartObject in this example). Chart is the relevant embedded Chart object.

  In the example below, Chart makes reference to Chart 1 (ChartObjects(“Chart 1”).Chart) within Sheet1 of the active workbook (Worksheets(“Sheet1”)). This statement uses the ChartObject.Chart property for purposes of returning the appropriate chart.

  

  Just as is the case when working with Application events, the statement above must be executed in order for the embedded chart event-handler procedures to work appropriately. Therefore, you may want to include the statement within the Workbook_Open Sub procedure. In such case, my comments above (when discussing the same situation for Application events) are generally applicable.

As explained by Bill Jelen and Tracy Syrstad in Excel 2016 VBA and Macros, chart events are the same for both chart sheets and embedded charts. I include these events in the list that you can find below.

The main difference between an event-handler procedure that deals with chart sheets and an event-handler dealing with embedded charts is related to the Sub procedure name. More precisely:

• When you’re dealing with a chart sheet, the name of the Sub procedure is generally of the following form:
  

  Chart_Event

  The following image shows how this looks like when working with the Chart.Activate event. Activate is the default event of the Chart object.

  

• When you’re working with an embedded chart, the Sub procedure’s name usually uses the following structure:
  

  chartObjectName_Event

  chartObjectName is the name you assign to the Public Chart object you declared in the relevant Class Module (step #2 above). If we continue with the same example as above, the name of the Sub procedure corresponding to the Chart.Activate event (which I explain below) is as follows:

  

Step #2: Start Writing The Code For Your Event-Handler Procedure

Strictly speaking, once you’re within the appropriate Code module, you can simply start writing the VBA code for your event-handler procedure.

However, as I mention above, (i) the names of event-handler procedures must follow certain rules and (ii) sometimes you’ll have to deal with the appropriate arguments.

You may be able to memorize the appropriate declaration statement (including name and arguments) for certain events. However, learning all of these details for the large number of existing events isn’t efficient. In fact…

It isn’t really necessary.

As I show below, the Visual Basic Editor can help you create your event-handler procedures by entering the appropriate declaration statement. This guarantees that you’re always using the appropriate procedure name and arguments.

Getting this declaration statement right is very important. As explained by John Walkenbach in Excel VBA Programming for Dummies:

If you don’t get the name exactly right, the procedure won’t work.

Step #1: Select The Appropriate Object

At the top of the Code Window for a particular object there are 2 drop-downs. Their default labels are usually as follows:

• (General).

  This is the Object drop-down list.

• (Declarations).

  This is the Procedure drop-down list.

Click on the Object drop-down menu and select the object you’re going to be working with. Within Object modules, there’s usually only 1 other option in addition to the default (General).

In other words:

• If you’re in a workbook module, select “Workbook”.

  

• If you’re in a worksheet module, select “Worksheet”,

  

• If you’re in a chart module, select “Chart”.

  

Within Class Modules, you’ll have 3 options: (i) (General), (ii) (Class), and (iii) the public Application or Chart object that you declared within the module. In this case, you should select the Application or Chart object. For example, in the screenshot below, I select applicationObject. applicationObject is the name I assigned to the public Application object in step #1 of the process to create a Class Module to deal with Application events above.

Once you’ve selected the appropriate object, the Visual Basic Editor includes the declaration and End statements for a particular Sub procedure. This Sub procedure is that corresponding to the default event of the applicable object. For example, in the screenshot below, my Visual Basic Editor has included the following statements:

• Private Sub Workbook_Open().
• End Sub

These statements make reference to an event-handler procedure that deals with the Workbook.Open event. I explain this particular event below. Open is the default event of the Workbook object.

If you want to work with the event to which the VBA code proposed by the VBE responds to (Workbook.Open in this example), you can start crafting your Sub procedure as usual. In other words, you can proceed to step #4 below.

However, the event to which the code suggested by the Visual Basic Editor makes reference to (Open in the example above) may not be the one you want to work with. In these cases, proceed to…

Step #2: Select The Appropriate Event

Click on the Procedure drop-down on the right side of the screen. The expanded drop-down list shows the events that apply to the object that you’ve selected in step #1 above.

For example, the following screenshot shows the drop-down list of events corresponding to the Workbook object:

You can scroll up or down as required. I provide a complete list of all the events that you can work with below.

From within this drop-down list, choose the event you want to work with. For example, in the case below, I select the Workbook.BeforeClose event.

Once you’ve selected the appropriate event, the Visual Basic Editor automatically enters new declaration and End statements for the Sub procedure that corresponds to the object and event you’ve selected in the previous step #1 and this step #2.

In the example above, these statements are the following:

• Private Sub Workbook_BeforeClose(Cancel As Boolean).
• End Sub

When entering the new declaration and End statements, the Visual Basic Editor doesn’t delete the previous suggestion.

Therefore, to maintain a clean module, you may want to proceed to…

Step #3: Delete The Code For The Sub Procedure You Aren’t Creating

If you won’t be working with the event to which the suggestion made by the VBE in step #1 above made reference to (the default event for the chosen object), you can delete it.

In the example we’re looking at, I delete the declaration and End statements for the Private Sub Workbook_Open.

Once you’ve completed the 3 steps above, you’re ready to move to…

Step #4: Code Your Sub Procedure

The statements of your VBA procedure go between the declaration and End statements that the Visual Basic Editor entered in the appropriate Object module or Class Module.

The following screenshot shows where this is for the Private Sub Workbook_BeforeClose.

Some event-handler procedures use arguments. For example, the Private Sub Workbook_BeforeClose procedure above uses one parameter called Cancel.

Your VBA code can work with these parameters. Usually, you can do either of the following within your event-handler procedure:

• Use the data that is passed.
• Change the value of the parameter.

  In particular, the Cancel parameter (in the example above) is a common event argument (as you’ll see below). Its default value is False, which indicates that the relevant event (closing the workbook in the example above) occurs. However, if your VBA code sets Cancel to True, the event (closing the workbook) is cancelled.

In the following sections, I provide a comprehensive list of Excel VBA events that will help you create your event-handler procedures. However, before we dig into that topic, it’s important to understand how I’ve organized this list.

List Of Excel VBA Events: Organization And Levels At Which You Can Monitor Events

In the following sections, I provide a comprehensive list of Excel VBA events. This list of events includes the following:

• Application events.
• Workbook events.
• Worksheet events.
• Chart events.

By my count, I’ve listed 115 events.

Explaining each event individually would make this VBA tutorial even longer. Therefore, I’ve grouped certain events into groups. The basic criteria I’ve used to group the events are the following:

• Criterion #1: What triggers them.

  Generally, if a few events are triggered by the same action, I group them together.

• Criterion #2: At what level (Application, workbook, worksheet or chart) can you monitor the occurrence of the event.

  Most of the events that I group together are triggered by the same action, but you can monitor them at different levels.

This VBA tutorial doesn’t focus on the topic of event sequencing. However, as you go through this list, please be aware that, as explained by Excel authorities Mike Alexander and Dick Kusleika in Excel 2016 Power Programming with VBA:

Some actions trigger multiple events.

In such case, the events occur in a particular sequence. This order may be relevant for certain of your event-handler procedures.

If you’re interested in learning more about which events fire when you do something in Excel, you can find applications that track which events are fire and in which sequence.

I may write further about the topic of event sequencing in future VBA tutorials. If you want to receive an email whenever I publish new material within Power Spreadsheets, please make sure to register for our Newsletter by entering your email address below:

Furthermore, some events that are substantially the same are available at different levels. An example of such group of events is composed of Application.SheetActivate, Workbook.SheetActivate, Worksheet.Activate and Chart.Activate (which I explain here). All of these events are triggered by the activation of an object. This object can be a sheet (both worksheet or chart) and, in the case of Chart.Activate, an embedded chart.

However, the scope at which these events are monitored varies:

• The Application-level event (Application.SheetActivate) is triggered when any sheet in any workbook is activated. In other words, it monitors the event at the Excel Application level.
• The Workbook-level event (Workbook.SheetActivate) occurs when any sheet within the relevant workbook is activated. In this case, the monitoring occurs at the workbook level.
• The Worksheet and Chart-level events fire when the object itself (worksheet, chart sheet or embedded chart) is activated. Therefore, the monitoring happens at the worksheet or chart level.

I’ve organized this list in these groups for convenience purposes only. There are, certainly, other ways in which you could classify the events.

In fact, if you don’t agree with the way in which I’ve organized the list of VBA events, you can:

1. Download the VBA Event Cheat Sheet by following the link above.
2. Quickly convert the PDF file to Excel using one of the methods I explain here.
3. Re-organize it to better suit your needs.

Now that this is clear, let’s start taking a look at the list of Excel VBA events:

Events Related To New Object Creation Or Deletion

Application.NewWorkbook

The Application.NewWorkbook event is triggered by the creation of a new workbook.

The event has a single parameter: Wb. Wb represents the newly created workbook.

Application.WorkbookNewSheet And Workbook.NewSheet

The NewSheet event is triggered whenever a new sheet (includes both worksheets and chart sheets) is created within a workbook.

NewSheet is available at the following levels:

• Application: With the Application.WorkbookNewSheet event.
• Workbook: With the Workbook.NewSheet event.

NewSheet has the following parameters:

• Wb: The workbook where the new sheet is created.

  Wb is only relevant at the Application level (Application.WorkbookNewSheet).

• Sh: Sh represents the newly created sheet.

Application.WorkbookNewChart And Workbook.NewChart

From a broad perspective, the NewChart event fires when you create a new chart in a workbook.

The NewChart event is available at the following levels:

• Application: With the Application.WorkbookNewChart event.
• Workbook: With the Workbook.NewChart event.

As a general rule, NewChart occurs when you either (i) insert or (ii) paste a new chart within a sheet. This includes both worksheets and chart sheets. However, the NewChart event doesn’t happen in the following 6 situations:

• Case #1: When you move a chart (object or sheet) from one location to another.

  There’s, however, an exception to this rule. If you move a chart from a chart object to a chart sheet, the event occurs. This is because, in such cases, Excel actually must “create” a new chart.

• Case #2: If you copy/paste a chart sheet.
• Case #3: Changing the chart type.
• Case #4: If you change the data source of a chart.
• Case #5: When you undo or redo a chart insertion or pasting.
• Case #6: Loading a workbook that contains charts.

If you insert or paste more than 1 new chart, the NewChart event occurs with respect to each of those charts. The order in which you insert the charts determines the order in which the NewChart event happens for each chart. In other words, in such cases, NewChart happens:

• First for the chart that you inserted first.
• Second for the chart that you inserted second.
• …
• Last for the chart you inserted last.

The NewChart event has the following arguments:

• Wb: The workbook where the new chart is created.

  Wb is only applicable to the Application.WorkbookNewChart event. It isn’t relevant for the Workbook.NewChart event.

• Ch: Ch is of the data type Chart. It represents the newly inserted chart.

Application.SheetBeforeDelete, Workbook.SheetBeforeDelete And Worksheet.BeforeDelete

The BeforeDelete event is triggered when a sheet is deleted.

BeforeDelete has the following versions:

• Application Level: The Application.SheetBeforeDelete event.
• Workbook Level: The Workbook.SheetBeforeDelete event.
• Worksheet Level: The Worksheet.BeforeDelete event.

At the Application (Application.SheetBeforeDelete) and workbook levels (Workbook.SheetBeforeDelete), this event applies to any sheet. This includes both worksheets and chart sheets. In such cases, the only parameter is Sh. Sh is the deleted sheet.

Events Related To Opening, Closing, Printing And Saving

Application.WorkbookOpen And Workbook.Open

The Open event happens when a workbook is opened.

You can work with the following versions of the event:

• Application Level: With the Application.WorkbookOpen event.
• Workbook Level: Using the Workbook.Open event.

The Application.WorkbookOpen event has a single parameter: Wb. Wb is the opened workbook.

The Workbook.Open event has no arguments.

Application.WorkbookBeforeSave And Workbook.BeforeSave

The BeforeSave event is triggered before an open workbook is saved.

You can monitor the BeforeSave event at the following levels:

• Application: With the Application.WorkbookBeforeSave event.
• Workbook: Using the Workbook.BeforeSave event.

BeforeSave has the following parameters:

• Wb: The saved workbook.

  Wb is only necessary for the Application.WorkbookBeforeSave event. It isn’t applicable to the Workbook.BeforeSave event.

• SaveAsUI: A Boolean. It’s True if Excel must display the Save As dialog box due to the existence of unsaved workbook changes.
• Cancel: A Boolean. By default, Cancel is False and the event occurs. You can set Cancel to True, in which case the workbook isn’t saved.

Application.WorkbookAfterSave And Workbook.AfterSave

The AfterSave event happens after a workbook is saved.

You can use the following versions of AfterSave:

• Application Level: The Application.WorkbookAfterSave event.
• Workbook Level: The Workbook.AfterSave event.

AfterSave has the following parameters:

• Wb: The saved workbook.

  Wb is only relevant for the Application.WorkbookAfterSave event.

• Success: Success returns True is the saving operation is successful. If the saving operation is unsuccessful, Success returns False.

Application.WorkbookBeforeClose And Workbook.BeforeClose

The rules that determine when the BeforeClose event happens are the following:

• Rule #1: If you’ve made changes to the workbook since it was last saved, BeforeClose happens before you’re asked to save the changes.

  

  Understanding this rule #1 is important. If you click the Cancel button in the dialog box above, Excel cancels the process of closing the workbook.

  

  However, by that point, the BeforeClose event has already been executed. This means, in effect, that the BeforeClose event can occur even without the workbook being actually closed.

• Rule #2: Other than the above rule #1, the general rule is that BeforeClose occurs before the workbook closes.

You can monitor the BeforeClose event at the following levels:

• Application: With the Application.WorkbookBeforeClose event.
• Workbook: Using the Workbook.BeforeClose event.

The BeforeClose event has the following parameters

• Wb: The closed workbook.

  This argument only applies to the Application-level event (Application.WorkbookBeforeClose).

• Cancel: A Boolean with the following possibilities:

  False: This is the default value passed to the procedure. In such a case, the event occurs.

  True: You can set Cancel to True within the procedure. In such case, (i) the operation of closing the workbook stops, and (ii) the workbook continues to be open.

Application.WorkbookBeforePrint And Workbook.BeforePrint

The BeforePrint event occurs before anything within the workbook (including the workbook as a whole) is printed. As explained in Excel 2016 Power Programming with VBA, the BeforePrint event also occurs if you preview the printing.

You can use the following versions of BeforePrint:

• Application Level: The Application.WorkbookBeforePrint event.
• Workbook Level: The Workbook.BeforePrint event.

The BeforePrint event has the following arguments:

• Wb: The printed workbook.

  Wb applies only to the Application.WorkbookBeforePrint event.

• Cancel: The Cancel parameter of BeforePrint behaves in a very similar manner to the Cancel parameter of the BeforeClose event above. More precisely:

  False: Is the value passed to the procedure. The event occurs.

  True: If you sent Cancel to True within the procedure, there’s no printing operation.

Events Related To Object Activation, Selection, Resizing And Mouse Clicks

Application.WorkbookActivate And Workbook.Activate

The Activate event (for a workbook) is triggered when a workbook is activated.

You can monitor the Activate event at the following levels:

• Application: Application.WorkbookActivate.
• Workbook: Workbook.Activate event.

If you’re working at the Application level (with Application.WorkbookActivate), the event has a parameter: Wb. Wb is the activated workbook.

Application.SheetActivate, Workbook.SheetActivate, Worksheet.Activate And Chart.Activate

The Activate event (for a sheet or chart) is triggered whenever a sheet or chart is activated.

You can monitor this event at the following levels:

• Application Level: Using the Application.SheetActivate event.
• Workbook Level: Use the Workbook.SheetActivate event.
• Worksheet Level: With the Worksheet.Activate event.
• Chart Level: Using the Chart.Activate event.

The Application.SheetActivate and Workbook.SheetActivate events apply to any sheet and include both worksheets and chart sheets.

In addition to occurring when a chart sheet is activated, the Chart.Activate event also fires when an embedded chart is activated.

For the cases of Application.SheetActivate and Workbook.SheetActivate, the only parameter of the event is Sh. Sh represents the activated sheet.

Worksheet.Activate and Chart.Activate don’t have parameters.

Application.WorkbookDeactivate And Workbook.Deactivate

The Deactivate (for a workbook) event fires when the relevant workbook is deactivated.

You can use Deactivate at the following levels:

• Application: With the Application.WorkbookDeactivate event.
• Workbook: With the Workbook.Deactivate event.

Application.SheetDeactivate, Workbook.SheetDeactivate And Worksheet.Deactivate

The Deactivate (for a sheet or chart) event happens when a sheet or chart is deactivated.

The Deactivate event is available in the following versions:

• Application Level: The Application.SheetDeactivate event.
• Workbook Level: The Workbook.SheetDeactivate event.
• Worksheet Level: The Worksheet.Deactivate event.
• Chart Level: The Chart.Deactivate event.

Application.SheetDeactivate and Workbook.SheetDeactivate apply to both worksheets and chart sheets. Both of these events have a single parameter: Sh. Sh is the relevant sheet.

Application.WindowActivate, Workbook.WindowActivate, Application.WindowDeactivate And Workbook.WindowDeactivate

The WindowActivate event happens when the workbook window is activated.

The opposite of WindowActivate is WindowDeactivate. The WindowDeactivate event occurs when a workbook window is deactivated.

You can refer to both the WindowActivate and WindowActivate events at the following levels:

• Application: Where the relevant events are Application.WindowActivate and Application.WindowDeactivate.
• Workbook: In which case you work with the Workbook.WindowActivate and Workbook.WindowDeactivate events.

Both WindowActivate and WindowDeactivate have the following parameters:

• Wb: The workbook that is displayed in the window that is activated or deactivated.

  The Wb parameter applies only to the Application-level events. That is, you only use Wb when working with Application.WindowActivate or Application.WindowDeactivate.

• Wn: The window that is activated or deactivated.

Application.SheetSelectionChange, Workbook.SheetSelectionChange And Worksheet.SelectionChange

The SelectionChange event occurs when the selection (cell or object) changes.

You can work with the following versions of this event:

• Application Level: The Application.SheetSelectionChange event.
• Workbook Level: The Workbook.SheetSelectionChange event.
• Worksheet Level: The Worksheet.SelectionChange event.

The Application.SheetSelectionChange and Workbook.SheetSelectionChange events don’t apply to selection changes in chart sheets.

SelectionChange has the following 1 or 2 parameters, depending on which version you’re using:

• Sh: The worksheet containing the new selection.

  Sh is only relevant for the Application.SheetSelectionChange and Workbook.SheetSelectionChange event.

• Target: The newly selected range.

Application.SheetBeforeDoubleClick, Workbook.SheetBeforeDoubleClick And Worksheet.BeforeDoubleClick

The BeforeDoubleClick event happens when a worksheet is double-clicked. However, the event doesn’t fire when you double-click the border of a cell.

You can use the following versions of the BeforeDoubleClick event:

• Application: With the Application.SheetBeforeDoubleClick event.
• Workbook: Using the Workbook.SheetBeforeDoubleClick event.
• Worksheet: With the Worksheet.BeforeDoubleClick event.

The Application.SheetBeforeDoubleClick and Workbook.SheetBeforeDoubleClick events don’t apply to chart sheets.

The BeforeDoubleClick event occurs just before the action that’s usually triggered by the double-click. For example, when you double-click on a cell, you can edit directly in the cell. In such a situation, the sequence goes roughly as follows:

• #1: You double-click on the cell.
• #2: The BeforeDoubleClick event occurs.
• #3: You can edit directly in the cell.

The BeforeDoubleClick event has the following parameters:

• Sh: The relevant worksheet (a Worksheet object).

  This parameter is only applicable for the Application.SheetBeforeDoubleClick and Workbook.SheetBeforeDoubleClick events. The Worksheet.BeforeDoubleClick event doesn’t have a Sh parameter.

• Target: A Range representing the “cell nearest to the mouse pointer” at the moment you double-click.
• Cancel: A Boolean which, by default, is False (the event occurs). You can set the Cancel argument to True, in which case Excel doesn’t carry out the default double-click action (editing directly in the cell in the example above).

Chart.BeforeDoubleClick

The Chart.BeforeDoubleClick event fires when a chart element is double-clicked.

Just as the SheetBeforeDoubleClick and Worksheet.BeforeDoubleClick events above, Chart.BeforeDoubleClick:

• Happens before the action that corresponds to the double-click by default.
• Isn’t triggered if you double-click the border of a cell.

The Chart.BeforeDoubleClick event has the following 4 parameters:

• Cancel: A Boolean whose default value is False (event occurs). If you set the Cancel argument to True, Excel doesn’t perform the default double-click action.
• Arg1: Additional event information, which depends on the value of ElementID. You can find the different ElementIDs and their meanings below.
• Arg2: Just as Arg1, Arg2 is additional event information that depends on ElementID’s value.
• ElementID: The object that you or the user actually double-click.

  As I mention above, the value of ElementID is what “determines the expected values of Arg1 and Arg2”.

Let’s take a look at the different ElementIDs you’re likely to find, as well as the consequences of each of these ElementIDs for the values of the Arg1 and Arg2 parameters:

ElementID Group #1: xlAxis, xlAxisTitle, xlDisplayUnitLabel, xlMajorGridlines and xlMinorGridlines

This first group of ElementIDs is composed of the following IDs:

• xlAxis.
• xlAxisTitle.
• xlDisplayUnitLabel.
• xlMajorGridlines.
• xlMinorGridlines

In all of these cases, the meaning of Arg1 and Arg2 is as follows:

• Arg1: AxisIndex.

  AxisIndex can take either of 2 xlAxisGroup constants:

  xlPrimary (1), indicating that the axis is primary.

  xlSecondary (2), which indicates that the axis is secondary.

• Arg2: AxisType.

  AxisType takes one of the following xlAxisType constants:

  xlCategory (1): Indicates that the axis displays categories.

  xlValue (2): Specifies an axis that displays values.

  xlSeriesAxis (3): Specifies that the axis displays data series.

ElementID Group #2: xlPivotChartDropZone

The meaning of Arg1 when the ElementID is xlPivotChartDropZone is DropZoneType. Arg2’s meaning is None.

DropZoneType specifies the drop zone type and can take the following values from the xlPivotFieldOrientation enumeration:

• xlRowField (1): Row.

  Row specifies the Category field.

• xlColumnField (2): Column.

  Column specifies the Series field.

• xlPageField (3): Page.
• xlDataField (4): Data.

ElementID Group #3: xlPivotChartFieldButton

When ElementID is xlPivotChartFieldButton, Arg1 and Arg2 have the following meanings:

• Arg1: DropZoneType.

  I introduce DropZoneType in the previous section.

• Arg2: PivotFieldIndex.

  PivotFieldIndex specifies the offset within the PivotFields collection for one of the following fields:

  #1: A specific Column (Series).

  #2: Specific Data.

  #3: A specific Page.

  #4: A specific Row (Category).

  The PivotFields object is a collection of all PivotField objects within a PivotTable report. The PivotField object represents a particular field within the PivotTable report.

ElementID Group #4: xlDownBars, xlDropLines, xlHiLoLines, xlRadarAxisLabels, xlSeriesLines and xlUpBars

This section covers the following ElementIDs:

• xlDownBars.
• xlDropLines.
• xlHiLoLines.
• xlRadarAxisLabels.
• xlSeriesLines.
• xlUpBars.

In any of such cases, the meaning of Arg1 is GroupIndex. Arg2’s meaning is None.

GroupIndex specifies the offset within the ChartsGroup collection for a particular chart group. The ChartGroups collection represents the series that are plotted in a particular chart and share the same format.

ElementID Group #5: xlChartArea, xlChartTitle, xlCorners, xlDataTable, xlFloor, xlLegend, xlNothing, xlPlotArea and xlWalls

This ElementID group is composed of the following:

• xlChartArea.
• xlChartTitle.
• xlCorners.
• xlDataTable.
• xlFloor.
• xlLegend.
• xlNothing.
• xlPlotArea.
• xlWalls

In any of these cases, the meaning of both Arg1 and Arg2 is None.

ElementID Group #6: xlErrorBars, xlLegendEntry, xlLegendKey, xlXErrorBars and xlYErrorBars

ElementID Group #6 is composed of the following:

• xlErrorBars.
• xlLegendEntry.
• xlLegendKey.
• xlXErrorBars.
• xlYErrorBars.

For these ElementIDs, Arg1 means SeriesIndex. SeriesIndex specifies the offset within the Series collection for a particular series. The Series collection contains all the series within a chart or chart group.

Arg2’s meaning is None.

ElementID Group #7: xlDataLabel and xlSeries

This section covers 2 ElementIDs:

• xlDataLabel.
• xlSeries

In both cases:

• Arg1’s meaning is SeriesIndex.

  I introduce SeriesIndex in the previous section.

• Arg2’s meaning is PointIndex.

  PointIndex specifies the offset within the Points collection for a particular point within a series. The Points collection contains all of the points within a chart series.

ElementID Group #8: xlTrendline

If ElementID is xlTrendline:

• The meaning of Arg1 is SeriesIndex.

  I provide an introduction to SeriesIndex in the section covering ElementID group #6 above.

• The meaning of Arg2 is TrendLineIndex.

  TrendlineIndex specifies the offset within the Trendlines collection for a particular trendline within a series. The Trendlines collection contains all of the trendlines for a particular chart series.

ElementID Group #9: xlShape

If ElementID is xlShape:

• Arg1’s meaning is ShapeIndex.

  ShapeIndex specifies the offset within the Shapes collection” for a particular shape. The Shapes collection contains all the shapes within a particular sheet.

• Arg2’s meaning is None.

Application.SheetBeforeRightClick, Workbook.SheetBeforeRightClick, Worksheet.BeforeRightClick And Chart.BeforeRightClick

The BeforeRightClick event is, to a certain extent, substantially similar to the previous BeforeDoubleClick event.

The main difference between BeforeRightClick and BeforeDoubleClick, as implied by their names, is on the way you click the mouse:

• BeforeDoubleClick occurs when a worksheet is double-clicked.
• BeforeRightClick happens (i) when a worksheet is right-clicked or (ii) in the case of the Chart.BeforeRightClick, when a chart element is right-clicked.

In other words, the BeforeRightClick event occurs (i) when a worksheet or chart element (for Chart.BeforeRightClick) is right-clicked, but (ii) before the default action that’s usually triggered by the right-click. For example, when you right-click on a cell, Excel generally displays a context menu.

Therefore, if you’re working with the BeforeRightClick event and right-click on a cell, the sequence occurs as follows:

• #1: You right-click.
• #2: The BeforeRightClick event fires.
• #3: Excel displays the contextual menu.

The RightClick event doesn’t fire if, when right-clicking, you place the mouse pointer on items such as a shape or command bar.

You can use the BeforeRightClick event at the following levels:

• Application: Use the Application.SheetBeforeRightClick event.
• Workbook: With the Workbook.SheetBeforeRightClick event.
• Worksheet: Using the Worksheet.BeforeRightClick event.
• Chart: Use the Chart.BeforeRightClick event.

Just as the SheetBeforeDoubleClick event above, Application.SheetBeforeRightClick and Workbook.SheetBeforeRightClick don’t apply to chart sheets.

BeforeRightClick has the same parameters as BeforeDoubleClick. More precisely:

• Sh: The Worksheet object that represents the worksheet.

  Sh is an argument only when you’re working at the Application (Application.SheetBeforeRightClick) or workbook level (Workbook.SheetBeforeRightClick). The Worksheet.BeforeRightClick event doesn’t have a Sh parameter.

• Target: The cell that is nearest to the mouse pointer when you right-click.
• Cancel: A Boolean with a default value of False (event occurs). If you set Cancel to True, the default right-click action (displaying a context menu in the example above) doesn’t happen.

Chart.Select

The Chart.Select event occurs when an element of the chart is selected.

The Chart.Select event has the 3 following parameters:

• ElementID: The chart element that is selected.
• Arg1: Additional information that depends on the value of ElementID.
• Arg2: Just as Arg1, additional event information dependent on the value of ElementID.

I provide a thorough description of ElementID, Arg1 and Arg2, as well as their relationship, in this section above.

Chart.MouseDown, Chart.MouseMove And Chart.MouseUp

The MouseDown, MouseMove and MouseUp events are all related to mouse movements over a chart. More precisely, these events are triggered when the following actions happen over a chart:

• Chart.MouseDown: A mouse button is pressed.
• Chart.MouseMove: The position of the mouse pointer changes.
• Chart.MouseUp: The mouse button is released.

All of these events have the same 4 parameters:

• Button: Indicates the mouse button that is pressed or released. It also indicates if no mouse button is pressed or released.
  
  The Button argument can be 1 of the 3 xlMouseButton constants:

  xlNoButton (0): No button.

  xlPrimaryButton (1): The primary mouse button. This is usually the left mouse button.

  xlSecondaryButton (2): The secondary mouse button. Usually, the right button is the secondary mouse button.

• Shift: Indicates the state of the Shift, Ctrl and Alt keys. Shift can be one of (or a sum of) values.
• x: The x coordinate of the mouse pointer. This is in chart object client coordinates.
• y: The y coordinate of the mouse pointer. This, just as x, is in chart object client coordinates.

Application.WindowResize And Workbook.WindowResize

The WindowResize event fires when the workbook window is resized.

You can monitor the WindowResize event at the following levels:

• Application: Application.WindowResize.
• Workbook: Workbook.WindowResize.

WindowResize has the following parameters:

• Wb: The workbook that is displayed within the resized window.

  Wb only applies to the Application.WindowResize event.

• Wn: The resized window.

Chart.Resize

The Chart.Resize event is triggered when the relevant chart is resized.

In Excel 2016 VBA and Macros, authors Bill Jelen (Mr. Excel) and Tracy Syrstad explain that Chart.Resize doesn’t occur if the size is changed by using the controls within “the Chart Tools, Format tab or Format Chart area task pane”.

Events Related To Changes And Calculations

Application.AfterCalculate

The Application.AfterCalculate event fires once the following activities and conditions are met:

• Condition #1: All refresh activity is completed. This includes both synchronous and asynchronous refresh activity.
• Condition #2: All calculation activities are completed.
• Condition #3: There aren’t any outstanding queries.

As a general rule, this event is the last calculation-related event to occur. What I mean is that it happens after the following:

• Application.SheetCalculate, Workbook.SheetCalculate, Worksheet.Calculate and Chart.Calculate.
• Application.SheetChange, Workbook.SheetChange and Worksheet.Change.
• QueryTable.AfterRefresh.
• The Application.CalculationState property is set to xlDone (meaning calculations are complete).

As a consequence of the above, the AfterCalculate event is commonly used to determine the moment in which all the data in a workbook has been completely updated by any applicable queries or calculations.

You can use the Applicaton.AfterCalculate event even if there’s no sheet data in the workbook.

Application.SheetCalculate, Workbook.SheetCalculate, Worksheet.Calculate And Chart.Calculate

You can work with the Calculate event at the following levels:

• Application: With the Application.SheetCalculate event.
• Workbook: With the Workbook.SheetCalculate event.
• Worksheet: Using the Worksheet.Calculate event.
• Chart: With the Chart.Calculate event.

The rules for triggering the event differ depending on the level you’re working at.

The Application.SheetCalculate and the Workbook.SheetCalculate events occur in the following 2 cases:

• Case #1: Any worksheet is recalculated.
• Case #2: Any changed or updated data is plotted on a chart.

The Worksheet.SheetCalculate event is triggered when the worksheet itself is recalculated.

The Chart.Calculate event fires when the relevant chart plots data that’s new or has changed.

At the Application (Application.SheetCalculate) and workbook levels (Workbook.SheetCalculate), the Sh parameter is used. Sh is the relevant chart or worksheet.

Application.SheetChange, Workbook.SheetChange And Worksheet.Change

The Change event fires when 1 or more cells in a worksheet are changed by either of the following:

• The user.
• A VBA Procedure.
• An external link.

The Change event isn’t triggered by a recalculation. For those purposes, please refer to the Calculate event.

Further to the above, as explained in Excel 2016 Power Programming with VBA, the Change event may behave unexpectedly. More precisely:

Some actions that should trigger the event don’t, and other actions that shouldn’t trigger the event do!

For example:

• The following actions trigger the Change event: (i) copying and pasting, or clearing, the formatting, (ii) deleting the contents of an empty cell, (iii) using the spell checker, (iv) doing a Find and Replace operation, (v) using AutoSum, or (vi) adding the Total Row to a table.
• The following don’t trigger the Change event: (i) merging cells, (ii) adding, editing or deleting cell comments, (iii) sorting a range, or (iv) using Goal Seek.

You can monitor the Change event at the following levels:

• Application: Using the Application.SheetChange event.
• Workbook: With the Workbook.SheetChange event.
• Worksheet: Use the Worksheet.Change event.

Application.SheetChange and Workbook.SheetChange don’t apply to chart sheets.

The SheetChange event has the following parameters:

• Sh: The relevant worksheet.

  This parameter applies only at the Application (Application.SheetChange) and workbook levels (Workbook.SheetChange).

• Target: The cell range that changes.

Events Related To Protected View Windows

Application.ProtectedViewWindowOpen

The Application.ProtectedViewWindowOpen event fires when an Excel workbook is opened within a Protected View window.

ProtectedViewWindowOpen has a single parameter: Pvw. Pvw represents the newly opened Protected View window.

Application.ProtectedViewWindowActivate And Application.ProtectedViewWindowDeactivate

The Application.ProtectedViewWindowActivate event fires when a Protected View window is activated.

The opposite event is Application.ProtectedViewWindowDeactivate. Application.ProtectedViewWindowDeactivate occurs when a Protected View window is deactivated.

The only parameter of both Application.ProtectedViewWindowActivate and Application.ProtectedViewWindowDeactivate is Pvw. Pvw is the activated or deactivated Protected View window.

Application.ProtectedViewWindowResize

The Application.ProtectedViewWindow event occurs when any Protected View window is resized.

The only argument of ProtectedViewWindowResize is Pvw. Pvw stands for the resized Protected View window.

Application.ProtectedViewWindowBeforeEdit

The Application.ProtectedViewWindowBeforeEdit event is triggered immediately before Excel enables editing on the workbook within a Protected View window.

ProtectedViewWindowBeforeEdit has the following 2 arguments:

• Pvw: The Protected View window holding the workbook with enabled editing.
• Cancel: A Boolean which is False by default (the event occurs).

  You can set the Cancel parameter to True. In such case, editing isn’t enabled on the applicable workbook.

Application.ProtectedViewWindowBeforeClose

The Application.ProtectedViewWindowBeforeClose event occurs immediately prior to the closure of either of the following:

• A Protected View window.
• A workbook in a Protected View window.

The ProtectedViewWindowBeforeClose event has the following 3 parameters:

• Pvw: The relevant Protected View window.
• Reason: A constant from the XlProtectedViewCloseReason enumeration that specifies how (the reason) the Protected View window is closed.

  Reason can take either of the following values:

  xlProtectedViewCloseEdit (1), which indicates that the user clicked on the Enable Editing button.

  xlProtectedViewCloseForced (2), indicating that Excel closed the Protected View window forcefully or stopped responding.

  xlProtectedViewCloseNormal (0), corresponding to the Protected View window being closed normally.

• Cancel: A Boolean which is False by default. In such a case, the event occurs.

  You can set Cancel to True within the procedure. In such case, Excel doesn’t close the Protected View window.

Events Related To PivotTables

Application.SheetPivotTableAfterValueChange, Workbook.SheetPivotTableAfterValueChange And Worksheet.PivotTableAfterValueChange

The PivotTableAfterValueChange happens after one or more cells within a PivotTable are either:

• Edited; or
• If the cell (or range of cells) contains formulas, recalculated.

The PivotTableAfterValueChange event only happens in these 2 cases. Therefore, the event isn’t triggered by (among others) any of the following operations:

• Operation #1: Refreshing the PivotTable.
• Operation #2: Sorting the PivotTable.
• Operation #3: Filtering the PivotTable.
• Operation #4: Drilling down on the PivotTable.

These 4 operations may result in changes in the PivotTable. Examples of this are the potential movement of cells or the retrieving of new values from the data source. Despite these potential effects in the PivotTable, the event we’re looking at isn’t triggered.

You can work with the following versions of PivotTableAfterValueChange:

• Application Level: Using the Application.SheetPivotTableAfterValueChange event.
• Workbook Level: With the Workbook.SheetPivotTableAfterValueChange event.
• Worksheet Level: Using the Worksheet.PivotTableAfterValueChange event.

PivotTableAfterValueChange has the following parameters:

• Sh: The worksheet containing the PivotTable.

  The Sh parameter is only relevant if you’re working with Application.SheetPivotTableAfterValueChange or Workbook.SheetPivotTableAfterValueChange. It doesn’t apply to the Worksheet.PivotTableAfterValueChange event.

• TargetPivotTable: The PivotTable containing the cell(s) that change(s).
• TargetRange: The range within the PivotTable containing the edited/recalculated cells.

Workbook.SheetPivotTableChangeSync And Worksheet.PivotTableChangeSync

The PivotTableChangeSync event occurs after most changes to a PivotTable. Some of the changes that are covered by the SheetPivotTableChangeSync event are the following:

• Clearing.
• Grouping.
• Refreshing.

PivotTableChangeSync is available at the workbook and worksheet level:

• Workbook: With the Workbook.SheetPivotTableChangeSync event.
• Worksheet: Using the Worksheet.PivotTableChangeSync event.

The PivotTableChangeSync event has 1 or 2 parameters, depending on whether you’re working at the workbook or the worksheet level. The possible arguments are as follows:

• Sh: The worksheet containing the PivotTable.

  This argument is only for the Workbook.SheetPivotTableChangeSync event. It’s not applicable for the Worksheet.PivotTableChangeSync event.

• Target: The PivotTable that changes.

Application.SheetPivotTableUpdate, Workbook.SheetPivotTableUpdate And Worksheet.PivotTableUpdate

The PivotTableUpdate event occurs after a PivotTable report is updated.

You can monitor the SheetPivotTableUpdate event at the Application, workbook and worksheet level:

• Application: Using the Application.SheetPivotTableUpdate event.
• Workbook: With the Workbook.SheetPivotTableUpdate event.
• Worksheet: Using the Worksheet.PivotTableUpdate event.

PivotTableUpdate has the 1 or 2 parameters depending on whether you’re working with the workbook or worksheet version. There arguments are virtually the same as those of PivotTableChangeSync above:

• Sh: The selected sheet.

  This applies only to the Application.SheetPivotTableUpdate and Workbook.SheetPivotTableUpdate events.

• Target: The selected PivotTable.

Application.WorkbookPivotTableCloseConnection, Workbook.PivotTableCloseConnection, Application.WorkbookPivotTableOpenConnection And Workbook.PivotTableOpenConnection

Both of these events (PivotTableCloseConnection and PivotTableOpenConnection) are related to the status of the connection between a PivotTable report and its data source. More precisely:

• PivotTableCloseConnection happens after a PivotTable report closes that connection.
• PivotTableOpenConnection occurs after the PivotTable report opens the connection.

These events are available at the following levels:

• Application: With the Application.WorkbookPivotTableCloseConnection and Application.WorkbookPivotTableOpenConnection events.
• Workbook: Using the Workbook.PivotTableCloseConnection and the Workbook.PivotTableOpenConnection events.

PivotTableCloseConnection and PivotTableOpenConnection have the following parameters:

• Wb: Wb is the relevant workbook.

  Wb is only applicable at the Application level. Therefore, it applies to the Application.WorkbookPivotTableCloseConnection and Application.WorkbookPivotTableOpenConnection events only.

• Target: The chosen PivotTable report.

PivotTableBeforeAllocateChanges, PivotTableBeforeCommitChanges And PivotTableBeforeDiscardChanges

All of the following events deal with changes to PivotTables and, therefore, the PivotTableChangeList collection. I explain each of these events individually in the following sections.

However, in order to understand how each of these events works, it may help if you have a basic idea about the following VBA constructs:

PivotTableChangeList Collection, ValueChange Object And ValueChange.Order Property

The PivotTableChangeList collection represents all of the changes you’ve made to the value cells within a PivotTable report that is based on an OLAP data source.

Each of the individual changes is represented by a ValueChange object.

ValueChange contains several properties that specify the details about the change(s) you’ve made. One of these properties is ValueChange.Order.

The Order property of ValueChange returns a value indicating the order in which a particular change (represented by a ValueChange object) is performed relative to the other changes held within the PivotTableChangeList collection. Excel assigns the value held by the ValueChange.Order property automatically. As a general rule, the value assigned corresponds to the order in which you’ve applied the changes to the PivotTable report. However, if a single operation results in multiple changes, the value assignment within that set of changes is made arbitrarily.

With these in mind, let’s start taking a look at the events covered in this section:

Application.SheetPivotTableBeforeAllocateChanges, Workbook.SheetPivotTableBeforeAllocateChanges And Worksheet.PivotTableBeforeAllocateChanges

PivotTableBeforeAllocateChanges happens before changes are applied to a PivotTable. More precisely, SheetPivotTableBeforeAllocateChanges occurs in the following sequence:

• #1: You (the user) chooses to apply changes to the PivotTable.
• #2: The SheetPivotTableBeforeAllocateChanges event happens.
• #3: Excel executes an UPDATE CUBE statement. This applies all the changes to the PivotTable.

The SheetPivotTableBeforeAllocateChanges event is available at the Application, workbook and worksheet levels:

• Application: Application.SheetPivotTableBeforeAllocateChanges.
• Workbook: Workbook.SheetPivotTableBeforeAllocateChanges.
• Worksheet: Worksheet.PivotTableBeforeAllocateChanges.

PivotTableBeforeAllocateChanges has the following 5 arguments:

• Sh: The worksheet with the PivotTable.

  This parameter is only relevant if you’re working with the Application.SheetPivotTableBeforeAllocateChanges or Workbook.SheetPivotTableBeforeAllocateChanges events. It doesn’t apply to the Worksheet.PivotTableBeforeAllocateChanges event.

• TargetPivotTable: The PivotTable containing the changes that the UPDATE CUBE statement applies.
• ValueChangeStart: The index to the first change within the applicable PivotTableChangeList collection. The index to this first change is specified by the ValueChange.Order property which I explain above.
• ValueChangeEnd: The index to the last change within the relevant PivotTableChangeList collection. Just as with ValueChangeStart, the index is specified by the Order property of the ValueChange object within the collection.
• Cancel: A Boolean that, by default is False. In such case, the event occurs.

  You can set Cancel to True within the relevant procedure. In such case: (i) changes aren’t applied, and (ii) edits are lost.

Application.SheetPivotTableBeforecommitChanges, Workbook.SheetPivotTableBeforeCommitChanges And Worksheet.PivotTableBeforeCommitChanges

The PivotTableBeforeCommitChanges occurs before changes are committed against the OLAP data source of a PivotTable. To be more precise, the relevant sequence is as follows:

• #1: You choose to save changes for the PivotTable.
• #2: The SheetPivotTableBeforeCommitChanges event occurs.
• #3: Excel executes a COMMIT TRANSACTION against the OLAP data source.

You can work with the following versions of this event:

• Application: The Application.SheetPivotTableBeforeCommitChanges event.
• Workbook: The Workbook.SheetPivotTableBeforeCommitChanges event.
• Worksheet: The Worksheet.PivotTableBeforeCommitChanges event.

The 5 parameters of PivotTableBeforeCommitChanges are virtually the same as those of PivotTableBeforeAllocateChanges above. Therefore, they’re as follows:

• Sh: The worksheet containing the relevant PivotTable.

  Sh only applies when you’re working at the Application or workbook levels with Application.SheetPivotTableBeforeCommitChanges or Workbook.SheetPivotTableBeforeCommitChanges. It doesn’t apply to Worksheet.PivotTableBeforeCommitChanges.

• TargetPivotTable: The PivotTable with the changes to commit.
• ValueChangeStart: The index to the first change within the PivotTableChangeList collection. The index is specified by the Order property I introduce above.
• ValueChangeEnd: The index to the last change within the PivotTableChangeList collection. This is also specified by the ValueChange.Order property.
• Cancel: False by default (event occurs). If you set Cancel to True, the changes “aren’t committed against the OLAP data source”.

Application.SheetPivotTableBeforeDiscardChanges, Workbook.SheetPivotTableBeforeDiscardChanges And Worksheet.PivotTableBeforeDiscardChanges

The PivotTableBeforeDiscardChanges event is triggered before changes to a particular PivotTable are discarded. The sequence in which PivotTableBeforeDiscardChanges occurs is quite similar to that of the previous PivotTableBeforeAllocateChanges and PivotTableBeforeCommitChanges events. More precisely:

• #1: You choose to discard changes.
• #2: SheetPivotTableBeforeDiscardChanges occurs.
• #3: Excel “executes a ROLLBACK TRANSACTION statement against the OLAP data source” if there’s an active transaction and the changed values are discarded.

You can work with the following versions of the PivotTableBeforeDiscardChanges event:

• Application Lever: Using the Application.SheetPivotTableBeforeDiscardChanges event.
• Workbook Level: With the Workbook.SheetPivotTableBeforeDiscardChanges event.
• Worksheet Level: Using the Worksheet.PivotTableBeforeDiscardChanges event.

The PivotTableBeforeDiscard event has the following arguments. Notice that they’re substantially the similar to the equivalent parameters of the previously explained events:

• Sh: The worksheet that contains the PivotTable.

  This parameter is only relevant for the Application.SheetPivotTableBeforediscardChanges and the Workbook.SheetPivotTableBeforeDiscardChanges events. It doesn’t apply to Worksheet.PivotTableBeforeDiscardChanges.

• TargetPivotTable: The PivotTable with the discarded changes.
• ValueChangeStart: The index to the first change within the PivotTableChangeList collection. This index is specified by the Order property, which I cover above.
• ValueChangeEnd: The index to the last change within the PivotTableChangeList collection. Just as in the case of ValueChangeStart, the index is specified by the ValueChange.Order property.

Application.WorkbookRowsetComplete And Workbook.RowsetComplete

The RowsetComplete event may help if you work with OLAP PivotTables. More precisely, RowsetComplete occurs when either of the following actions is completed in connection with an OLAP PivotTable:

• Action #1: Drill through a recordset.
• Action #2: Calls the rowset action.

You can monitor the RowsetComplete event at the following levels:

• Application: With the Application.WorkbookRowsetComplete event.
• Workbook: With the Workbook.RowsetComplete event.

RowsetComplete isn’t available at the worksheet level. The reason for this is that (generally) the recordset is created on a separate sheet. As a consequence of this, the event needs to be at the workbook or Application level.

RowsetComplete has the following parameters:

• Wb: The workbook for which the Application.WorkbookRowsetComplete event happens.

  This argument isn’t applicable to the Workbook.RowsetComplete event.

• Description: A string that describes the event.
• Sheet: The worksheet in which the relevant recordset is created.
• Success: A Boolean indicating success or failure.

Events Related To Add-Ins: Application.WorkbookAddinInstall, Workbook.AddinInstall, Application.WorkbookAddinUninstall And Workbook.AddinUninstall

The AddinInstall event occurs when the relevant workbook is installed as an add-in.

The AddinUninstall event is the opposite. Therefore, it happens when the workbook is uninstalled as an add-in.

As explained by Bill Jelen (Mr. Excel) and Tracy Syrstad in Excel 2016 VBA and Macros:

• The events make reference to installation and uninstallation of an add-in. The events aren’t triggered by the mere opening or closing of a workbook.
• The AddinUninstall event doesn’t close the workbook automatically.

You can monitor both of these events at the following levels:

• Application Level: With the Application.WorkbookAddinInstall and Application.WorkbookAddinUninstall events.
• Workbook Level: With the Workbook.AddinInstall event and the Workbook.AddinUninstall event.

The Application-level events (Application.WorkbookAddinInstall and Application.WorkbookAddinUninstall) have a parameter: Wb. This argument represents the relevant (installed) workbook.

Events Related To The Excel Data Model

Application.WorkbookModelChange And Workbook.ModelChange

The ModelChange event is triggered after there’s a change to Excel’s data model.

You can use the following versions of the ModelChange event:

• Application Level: Application.WorkbookModelChange.
• Workbook Level: Workbook.ModelChange event.

The ModelChange event has the following arguments:

• Wb: The relevant workbook.

  This argument is only relevant for the Application.WorkbookModelChange event.

• Changes: Changes is a ModelChanges object.

  The ModelChanges object represents the changes made to the data model. In other words, ModelChanges has information about which are the changes (you can make several in a single operation) made to the data model when a model change (the ModelChange event) occurs.

Application.SheetTableUpdate, Workbook.SheetTableUpdate And Worksheet.TableUpdate

TableUpdate is triggered after a Query table that is connected to the data model is updated.

The TableUpdate event is available at the Application, workbook and worksheet levels:

• Application: Using the Application.SheetTableUpdate event.
• Workbook: With the Workbook.SheetTableUpdate event.
• Worksheet: Using the Worksheet.TableUpdate event.

The TableUpdate event has the following parameters:

• Sh: The relevant worksheet.

  You only need to consider Sh when working with Application.SheetTableUpdate or Workbook.SheetTableUpdate. It’s not applicable to Worksheet.TableUpdate.

• Target: The relevant Query table with data from the data model.

Events Related To XML Data

Application.WorkbookAfterXmlExport, Workbook.AfterXmlExport, Application.WorkbookBeforeXmlExport And Workbook.BeforeXmlExport

The AfterXmlExport and BeforeXmlExport events are connected to either the (i) saving or (ii) exporting of XML data from the relevant workbook.

More precisely:

• AfterXmlExport occurs after Excel either (i) saves or (ii) exports XML data from the relevant workbook.
• BeforeXmlExport happens before Excel carries out either of these actions.

You can monitor these events at the following levels:

• Application: With the Application.WorkbookAfterXmlExport and Application.WorkbookBeforeXmlExport events.
• Workbook: With the Workbook.AfterXmlExport event and the Workbook.BeforeXmlExport event.

AfterXmlExport has the following parameters:

• Wb: The relevant target workbook.

  Wb is only applicable to the Application.WorkbookAfterXmlExport event.

• Map: The XML schema map used for the saving or exporting of the data. Map is of the data type XmlMap.
• Url: The location of the exported XML file. You specify Url as a string.
• Result: The result of the saving or exporting operation. This can be one of the 2 xlXmlExportResult constants:

  xlXmlExportSuccess (0): The operation was successful.

  xlXmlExportValidationFailed (1): The contents of the XML file don’t match the schema map.

BeforeXmlExport has the following parameters. Only the fourth parameter (Cancel in BeforeXmlExport vs. Result in AfterXmlExport) differs materially from the arguments of AfterXmlExport above:

• Wb, which is only applicable for purposes of using the Application.WorkbookBeforeXmlExport event.
• Map.
• Url.
• Cancel: A Boolean. The default value is False. If you set Cancel to True, the save or export operation is cancelled.

The BeforeXmlExport doesn’t happen when you’re saving to the XML Spreadsheet file format.

Application.WorkbookAfterXmlImport, Workbook.AfterXmlImport, Application.WorkbookBeforeXmlImport And Workbook.BeforeXmlImport

The AfterXmlImport and BeforeXmlImport events are related to either the (i) refreshment of existing XML data connections, or (ii) import of new XML data into the workbook. AfterXmlImport occurs after either of these. BeforeXmlImport is triggered before them.

These events are available at the following levels:

• Application: With the Application.WorkbookAfterXmlImport event and the Application.WorkbookBeforeXmlImport event.
• Workbook: With the Workbook.AfterXmlImport event and the Workbook.BeforeXmlImport event.

Similar to what occurs with the previous events (AfterXmlExport and BeforeXmlExport), AfterXmlImport has the following parameters:

• Wb: The relevant workbook.

  Wb is only applicable to the Application.WorkbookAfterXmlImport event. It’s not an argument of the Workbook.AfterXmlImport event.

• Map: The XML map used for the import of data. As I explain above, Map is of the data type XmlMap.
• IsRefresh: A Boolean making reference to the way in which the AfterXmlImport event is triggered. More precisely:

  If the AfterXmlImport event is triggered because an existing connection to XML data is refreshed, IsRefresh is True.

  If the event is triggered due to the data being imported from a different data source, IsRefresh is False.

• Result: Just as in the case of the AfterXmlExport event, Result indicates the result of the operation. However, in the case of AfterXmlImport, the relevant operation is a refresh or import. In this case, Result can be one of the 3 xlXmlImportResult constants:

  #1: xlXmlImportSuccess (0): The XML data file import was successful.

  #2: xlXmlImportElementsTruncated (1): The XML data file is too large for the relevant worksheet. Therefore, the contents of the XML data file are truncated.

  #3: xlXmlImportValidationFailed (2): The contents of the XML data file don’t match the relevant schema map.

BeforeXmlImport, on the other hand, has the following arguments. 2 of those arguments (Map and Refresh) are substantially similar to those of the AfterXmlImport event. The other parameters (Wb, Url and Cancel) are quite similar to the relevant parameters of BeforeXmlExport above.

• Wb: The workbook. This argument is only relevant for the Application.WorkbookBeforeXmlImport event.
• Map.
• Url: The location of the exported XML file. Just as in the case of AfterXmlExport and BeforeXmlExport, you specify Url as a string.
• IsRefresh.
• Cancel: A Boolean which you can set to True in order to cancel the import/refresh operation.

Other Events

Application.SheetFollowHyperlink, Workbook.SheetFollowHyperlink And Worksheet.FollowHyperlink

The FollowHyperlink event is triggered whenever you click a hyperlink.

You have access to the FollowHyperlink event at the following levels:

• Application: Using the Application.SheetFollowHyperlink event.
• Workbook: With the Workbook.SheetFollowHyperlink event.
• Worksheet: Using the Worksheet.FollowHyperlink event.

FollowHyperlink has the following arguments:

• Sh: The Worksheet object where the hyperlink is.

  Sh is only applicable to the Application.SheetFollowHyperlink and Workbook.SheetFollowHyperlink events. It doesn’t apply at the worksheet level with Worksheet.FollowHyperlink.

• Target: The relevant Hyperlink object.

Application.SheetLensGalleryRenderComplete, Workbook.SheetLensGalleryRenderComplete And Worksheet.LensGalleryRenderComplete

As explained in Excel 2016 VBA and Macros, the LensGalleryRenderComplete event fires when you select the Quick Analysis Tool.

You can use the following versions of LensGalleryRenderComplete:

• Application: The Application.SheetLensGalleryRenderComplete event.
• Workbook: The Workbook.SheetLensGalleryRenderComplete event.
• Worksheet: Worksheet.LensGalleryRenderComplete.

At the Application (Application.SheetLensGalleryRenderComplete) and workbook (Workbook.SheetLensGalleryRenderComplete) levels, the only parameter of the event is Sh. Sh is a Worksheet object.

Non-Object Events

There are 2 events that aren’t associated with a certain object from within Excel’s object model. You access both of the following events through methods of the Application object.

As explained by John Walkenbach in Excel VBA Programming for Dummies:

Because time and keypresses aren’t associated with a particular object such as a workbook or a worksheet, you program these events in a normal VBA module.

Application.OnTime

You can use the Application.OnTime method for purposes of specifying that a particular procedure runs at a certain time in the future. You can specify the time either of the following ways:

• As a specific time of the day.
• As a time occurring after a certain amount of time passes.

The basic syntax of Application.OnTime is as follows:

expression.OnTime(EarliestTime, Procedure, LatestTime, Schedule)

The following are the 4 parameters of this method:

• EarliestTime: A required argument. You use it to specify the time where you want the procedure to be executed. The value you provide is rounded to the nearest second.
• Procedure: A required parameter that you use to specify (as a String) the name of the procedure that should run at EarliestTime.
• LatestTime: An optional parameter. You can use LatestTime to specify the latest time at which the procedure can be executed. If you specify LatestTime and, by that time, Excel isn’t ready to execute the procedure, the procedure doesn’t run at all.

  If you omit LatestTime, Excel simply waits as long as necessary until it can execute the procedure.

• Schedule: Another optional parameter that can take the values of True and False. Schedule allows you to determine whether to (i) schedule a new procedure (True), or (ii) clear a previously set OnTime procedure (False). This may be relevant if you need to clear “a procedure previously set with the same Procedure and EarliestTime values”.

  Schedule’s default value is False, which clears a previously set procedure.

As explained by Excel guru John Walkenbach in Excel VBA Programming for Dummies, “the OnTime event persists even after the workbook is closed” if you leave Excel open. Therefore, make sure that you set up the appropriate VBA code to clear as necessary. You can do this by, for example, setting up a procedure that:

• #1: Is triggered when the BeforeClose event occurs.
• #2: Sets the Schedule parameter of the Application.OnTime method to False.

Application.OnKey

The Application.OnKey method allows you to specify a key or key combination that, when pressed, executes a particular procedure.

The OnKey method works because Excel is always monitoring the keys you press. This allows you to set up the equivalent of a keyboard shortcut: a particular key or key combination executes a procedure.

As explained by Excel authorities Mike Alexander and Dick Kusleika in Excel 2016 Power Programming with VBA, there are 2 cases that are an exception to the rule above. In the following situations, Excel doesn’t apply the OnKey method:

• If you’re entering a formula.
• If you’re working with a dialog box.

Even though, strictly speaking, you can use Application.OnKey for purposes of creating a keyboard shortcut for your macros, that’s not the most appropriate way to proceed. In order to assign a keyboard shortcut to execute a Sub procedure, you should generally rely on Excel’s built-in tools. These are the Record Macro dialog (if you’re using the macro recorder) or the Macro dialog box.

The syntax of Application.OnKey is as follows:

expression.OnKey(Key, Procedure)

The OnKey method has the 2 following parameters:

• Key: The key or key combination that triggers the procedure execution.

  You specify Key as a string. I explain the main rules you must consider for purposes of specifying Key below.

• Procedure: The procedure that Excel should run when you press Key. There are a couple of special cases that you should consider:

  Case #1: If you specify Procedure as empty text (“”), Excel doesn’t do anything when Key is pressed. Specifying Procedure as empty text, then, has the consequence of disabling the keystroke or keystroke combination you specify as Key. In other words, Excel simply ignores that you pressed the key or key combination.

  Case #2: If you omit Procedure, (i) any previous assignments done with OnKey are cleared, and (ii) the keystroke combination specified as Key returns to its default meaning.

Key can be (i) a single key combined with Alt, Ctrl or Shift, or (ii) a combination of these keys. The following are the main rules you should consider when specifying Key:

• Rule #1: Every key is represented by a particular character or group of characters.
• Rule #2: Numbers, letters and other characters that are displayed upon you pressing the relevant key, are specified by that key.

  For example, in order to specify the letter a, you include “a” in your code.

• Rule #3: In order to specify characters that aren’t displayed when you press a key (for example Backspace, Delete or Esc), you use the codes that appear in the following table:
  

  Key	OnKey Code
  Backspace	{BACKSPACE} or {BS}
  Break	{BREAK}
  Caps Lock	{CAPSLOCK}
  Clear	{CLEAR}
  Delete or Del	{DELETE} or {DEL}
  Down Arrow	{DOWN}
  End	{END}
  Enter	{ENTER} (numeric keypad) or ~ (tilde)
  Esc	{ESCAPE} or {ESC}
  Help	{HELP}
  Home	{HOME}
  Ins	{INSERT}
  Left Arrow	{LEFT}
  Num Lock	{NUMLOCK}
  Page Down	{PGDN}
  Page Up	{PGUP}
  Return	{RETURN}
  Right Arrow	{RIGHT}
  Scroll Lock	{SCROLLLOCK}
  Tab	{TAB}
  Up Arrow	{UP}
  F1 through F15	{F1} through {F15}

• Rule #4: If you want to specify a combination of a key with (i) Shift, (ii) Ctrl or (iii) Alt, use the following codes:
  

  Key	OnKey Code
  Shift	+ (plus)
  Ctrl	^ (caret)
  Alt	% (percent)

• Rule #5: In order to specify some characters whose keys have special meanings, you must surround them with curly braces ({ }). Some of the keys falling within the scope of this rule #5 are plus (+), caret (^), parentheses (( )), tilde (~), brackets ([ ]) and curly braces themselves ({ }).

Similar to the previously explained Application.OnTime method, Application.OnKey doesn’t reset when you close the workbook and leave Excel open. Therefore, it’s also important that you set up the appropriate code to clear the assignments done with OnKey. You can do this by creating a procedure that:

• #1: Is launched upon the BeforeClose event occurring.
• #2: Omits the Procedure argument of Application.OnKey.

Deprecated Or Non-Functional Events

There are some events that have been deprecated and/or are non-functional. Microsoft keeps them within the object model for purposes of backward compatibility. Generally, you should avoid using this events within your VBA applications.

The following are these deprecated/non-functional events:

• Application.WorkbookSync and Workbook.Sync.
• Chart.SeriesChange.

Why An Event-Handler Procedure Isn’t Automatically Executed And Possible Solutions

Once you’ve created an event-handler procedure, you probably want to ensure that Excel runs the macro when the relevant event happens.

There are a few reasons why an event-handler procedure isn’t triggered when you expect it to. However, in my experience, one of the most common reasons why a particular event-handler procedure isn’t executed when expected is that macros aren’t enabled.

I cover the topic of enabling macros in the Complete Guide On How To Enable Macros In Excel. In that blog post, I cover topics such as the following:

• How to change your macro security settings in order to enable macros by default.
• How to enable macros for certain Excel files.
• How to enable macros for a single time.

Event-handler procedures may also fail to execute if events are disabled. Events are, by default, enabled. However, you can control whether events are enabled or disabled through the Application.EnableEvents property.

More precisely, the following VBA statements allow you to enable or disable events:

• To enable events, set the EnableEvents property to True.
  

  Application.EnableEvents = True

• To disable events, set Application.EnableEvents to False.
  

  Application.EnableEvents = False

Note that, since EnableEvents is a property of the Application object, it applies to all Excel workbooks.

There are some legitimate reasons why you would want to disable events in certain circumstances. As explained in Excel 2016 Power Programming with VBA:

One common reason is to prevent an infinite loop of cascading events.

An infinite loop of cascading events may occur if, for example, in the following situation:

• Step #1: You set up an event-handler procedure that is triggered by a particular event (let’s call it “X”).
• Step #2: X occurs and, therefore, Excel executes the event-handler procedure.
• Step #3: The event-handler procedure itself causes changes that result in event X occurring again.
• Step #4: Since X occurs again, Excel executes the event-handler procedure again.
• Step #5: Step #3 occurs again.

Such a loop looks roughly as follows:

There are several ways in which you can avoid the problem of potential infinite loops of cascading events. The following is a common suggestion:

1. Disable events at the beginning of your event-handler Sub procedure.
2. Re-enable events just before the end of the event-handler procedure.

You disable and re-enable events using the statements I explain above.

There are other ways in which you can deal with the potential problem of infinite loops of recursive events. The following are 2 examples:

1. Using a global variable. Although this isn’t a great programming practice.
2. Using a Boolean variable within the Class Module containing the relevant events.

Conclusion

After reading this tutorial, you’re ready to start using Excel VBA events within your macros.

In addition to knowing what are VBA events and why are they useful, you have a thorough knowledge of the most relevant events. For example, you’re aware of:

• The differences between Application, workbook, worksheet and chart events.
• How to create event-handler procedures for all of these events.
• What are the main events at the Application, workbook, worksheet and chart level to which your VBA applications can respond to.

  This Excel VBA Events Tutorial is accompanied by a Cheat Sheet. You can get immediate free access to this Cheat Sheet by subscribing to the Power Spreadsheets Newsletter.

• What are the Application.OnTime and Application.OnKey methods, and how you can use them.

You also know what are the most common reasons explaining why an event-handler procedure isn’t triggered when the corresponding event occurs, and how you can address some of these problems.

Books Referenced In This Excel VBA Tutorial

• Alexander, Michael (2015). Excel Macros for Dummies. Hoboken, NJ: John Wiley & Sons Inc.
• Alexander, Michael and Kusleika, Dick (2016). Excel 2016 Power Programming with VBA. Indianapolis, IN: John Wiley & Sons Inc.
• Jelen, Bill and Syrstad, Tracy (2015). Excel 2016 VBA and Macros. United States of America: Pearson Education, Inc.
• Walkenbach, John (2015). Excel VBA Programming for Dummies. Hoboken, NJ: John Wiley & Sons Inc.