Excel VBA – Event Procedures

Most of the time when you write a macro, it’s one that you will run by clicking on a button on the Quick Access Toolbar, or from a button on the Ribbon, or even directly within your Visual Basic Editor. Whichever method you use, the code is running on demand.

If you write code that other people may end up using, from a workbook on a shared drive for example, relying on users to run code is very much hit and miss. Some will be reliable and click on the right button at the appropriate moment. Others…..forget it.

So how can you force the user to run code at the right time?

What you need is an EVENT PROCEDURE. Unlike a normal sub routine that has to be manually kick started, an EVENT PROCEDURE automatically runs if the user does something within your workbook.

EVENT PROCEDURES take place at either workbook or individual worksheet levels within a workbook. The types of events vary at each level.

When you look at your PROJECT EXPLORER window you will see the names of any sheets in the workbook as well as something called THISWORKBOOK.

Finding ThisWorkbook in the VBA Editor project explorer window

Finding ThisWorkbook in the VBA Editor project explorer window

It is here, in either (or both) at worksheet and/or workbook level that you will add your EVENT PEOCEDURES, not in modules as you do with normal sub routines.

Let’s start with WORKBOOK level procedures.

Double click THISWORKBOOK. This will open a blank sheet to write code, but we don’t want to use this. Click on the drop down on the right hand side above the work area and select WORKBOOK.

ScreenHunter_205 Oct. 07 17.43

Getting to the Workbook scripting area

After clicking on WORKBOOK you should see this;

Default event at Workbook level

Default event at Workbook level

The editor automatically selects an event. Nothing you can do about this. It doesn’t mean you have to do anything with this, it’s just the default event to appear at workbook level.

There are a number of events that you can choose from. To see the full list go to the top right hand corner and click on the dropdown.

Workbook level event options

Workbook level event options

Use the scrollbar to view all the events available to you at Workbook level.

There are also events that run at WORKSHEET level. Double click on any of the sheets in your workbook and you get a blank sheet for code, identical to what happened when we wanted to create an event at workbook level. Where it says GENERAL, click on the drop down and this time select WORKSHEET.

Selecting Worksheet level

Selecting Worksheet level

As with WORKBOOK events, the editor will display a default event. In the case of WORKSHEET it’s SELECTION CHANGE.

Default event at Worksheet level

Default event at Worksheet level

If that’s not the event you want, click on the drop down on the right hand side where you can see SELECTION CHANGE. There are not as many options at this level as there were at WORKBOOK level, but still enough to keep you entertained.

Worksheet level event options

Worksheet level event options

Again, use the scroll bar to see all available options.

Whether it is an event at WORKBOOK or WORKSHEET level, simply add your code as normal. Unless you know your events inside out and the variables they require, don’t try to get creative editing the opening line i.e. Private Sub… into the event you want. Pick the event you want from the drop down list and delete whichever one you don’t need from the editor sheet. If you try to edit the opening line, chances are you’ll dig yourself into an extremely deep hole from which you will probably never escape.

The most common mistake people make when starting to use events is to type in a command line that does the event. If you are not sure what I mean here are a couple of typical mistakes as examples;

Typical event errors by beginners

Typical event errors by beginners

In a workbook called MyWorkbook the user wants something to happen when they open it. Unfortunately,  a line has been added that opens the very book they just opened. Don’t do it.

On a NEWSHEET event, whenever a user adds a new sheet, the code then adds yet another new sheet to the workbook and prompts the user to name this sheet rather than the one the user added.

Now…these two may seem like minor issues, but you don’t need to write an action to do what has already happened. Remember, it is the opening of the workbook by the user that triggers some code, so there is no need to write code that opens the workbook that has just been opened. In the same way, when someone clicks on the NEW SHEET button or right clicks and selects INSERT, you don’t want to add yet another blank sheet…the user has just created the event that triggers some code to run.

By all means, when a workbook is opened, open one or two more as these may be required. Effectively, you are making sure that the user is provided with all the workbooks they need to complete a task, and therefore eliminating any risk that the user forgets to open the others.

And that is really what you are doing with events in many cases – eliminating risk;

  • Before closing a workbook make sure a copy of the workbook is saved in the correct folder in the correct drive
  • Before saving changes to a workbook make sure all cells that need to be filled in have been
  • If a new sheet is added, or a new version of a workbook is created, set the correct naming convention for sheets and workbooks etc. the possibilities are almost endless

An interesting example is one by Tom Urtis, getting a workbook to delete itself. http://www.atlaspm.com/toms-tutorials-for-excel/toms-tips-for-excel-workbook-suicide/

Or if you want to have a bit of fun and annoy people, try this;

VBA fun...strictly for geeks ;)

VBA fun…strictly for geeks 😉

Highly annoying!

So don’t be afraid of using EVENT PROCEDURES. They can be very useful (ignoring the annoying example above) and can ensure that what you want to happen with your workbook actually does, without having to rely on users remembering to do things, which more often than not, doesn’t happen.

 

Advertisements

Posted on October 28, 2015, in Events, VBA and tagged , , . Bookmark the permalink. 2 Comments.

  1. Great write up, but a little misleading. Event procedures are much more than what you’ve described here. In fact, responding to a button click *requires* an event procedure too. If you want to level up, look into having your own custom classes raise events.

    • Agreed that there are lot of possibilities with events, and for that matter with just about any bit of code. My VBA blogs are aimed primarily at novices or people completely new to VBA, so although you are technically correct, a click of button triggers an event, explaining to beginners that clicking on a button is an event and that not clicking on a button can also an event, you can imagine the confusion it will cause. As a trainer, I come across all abilities in all topics I cover and have found that simplicity is the key to getting people to get that initial understanding and clarity. The additional complexity then comes through use and experience. I have to say that so far, when I have been shown the use of classes I have been less than impressed. If you have examples of good/practical use for classes then I’d be interested in seeing them. Thanks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: