Excel миф on time

Schedule a Macro with VBA Application.OnTime

The VBA Tutorials Blog

Programmers love to make things more efficient. Pushing buttons just to make a code run is particularly annoying, especially when the code is supposed to run at the same time every time. Fortunately, Excel makes scheduled macro automation simple with the Application.OnTime method.

The Application.OnTime Method

The Application.OnTime method is part of the Application object, which means it lives inside Excel’s main application. If you’re using Intellisense, when you type Application.OnTime , you should see this:

Notice there are four arguments, two of which are optional:

• EarliestTime is the time you want your specified macro to start running
• Procedure is the name of the macro you want to call, which can be in the same workbook or another workbook
• LatestTime is optional, and it specifies the last time the macro can be run. It puts a limit or deadline on the latest time Excel will attempt to start the macro, and if the deadline is missed, the macro is not executed
• Schedule is used for canceling previously scheduled OnTime macros

Scheduling the Macro

There are many ways to schedule your macros to run using the OnTime method. The most common ways are via specific times (1am, 11:45, 19:30) or a time relative to the existing time. You can also make other scheduling decisions, like scheduling a macro to run relative to a future date based on some user input.

Again, the argument EarliestTime is your start time, and the scheduling mechanism will try to execute the specified macro at this time. As long as nothing prevents the called macro from running, this is synonymous with the start time. Conversely, if there is something preventing the called macro from running, LatestTime is essentially the time at which Excel stops trying to run the macro.

Specific Times

If a task must be run every day at the same time, it makes sense to apply the specific time technique. Let’s say you have to run a macro every day at 7am before you come into the office. You would execute a code snippet like this to make sure your macro runs before you even arrive:

In this example, early_morning_task is the name of the macro you have to run at 7am.

You could also use the TimeSerial function or the CDate function if you were grabbing your times from user-input variables:

Make powerful macros with our free VBA Developer Kit

It’s easy to copy and paste a macro like this, but it’s harder make one on your own. To help you make macros like this, we built a free VBA Developer Kit and wrote the Big Book of Excel VBA Macros full of hundreds of pre-built macros to help you master file I/O, arrays, strings and more — grab your free copy below.

Notice the use of CInt to ensure the value going into TimeSerial is an integer. Also, note that this setup uses 24-hour format, and you will need to account for that by explicitly forcing users to use 24-hour formats, making an educated guess (programmatically!), or by offering the option of entering AM/PM and calculating the 24-hour format of the input.

Relative Times

You can also schedule macros to run at relative times. The most common way is to schedule it relative to the current time. You would do this by using the Now function to grab the current time then adding some amount of time to it.

The DateAdd function is a good option if you want to add two times together, and it plays well with the Now function. The following snippet fires off the macro nseconds from now, where nseconds is determined by the user.

If you’re scheduling over longer time periods, you can change the “s” to an “m” for minutes or “h” for hours and adjust the prompt.

Remember that a macro is executed line-by-line, so if the InputBox opens at 19:33:09 and the user waits 10 seconds then enters 15, the macro will fire at 19:33:34, not at 19:33:24.

Specifying the Macro

When you only have a single workbook, you can reference the macro directly by using its name. To write more robust code, you can specify the module to ensure no future changes to the workbook, like adding another module with an identically-named macro, will cause issues.

In this snippet, we are running the macro_to_schedule from Module2. If the Application.OnTime line runs in Module1 and there is a macro entitled macro_to_schedule there, we must specify we want the identically-named macro from Module2 . It’s certainly allowed, but I don’t recommend naming your macros exactly the same in different modules because it can become confusing for a human.

Scheduling Macros in Other Workbooks

Believe it or not, you can extend the Application.OnTime method to other workbooks, even if they have identically-named macros. I have plenty of workbooks that have subroutines named main , for example.

Keep in mind that Application.OnTime lives at the application level and schedules there, so you can run the OnTime method from one workbook and it will execute macros in another workbook as long as you properly specify the name of the other workbook. A call to a workbook named Other Workbook.xlsm with a macro named main in it will look like this:

Don’t forget that Excel uses ! to separate the workbook name from the Modules and Sheets but uses . to separate the Module/Sheet from the macro.

Scheduling Macros in Closed Workbooks

This extends even further to closed workbooks. Since the scheduling happens at the application level, as long as the application is open, the scheduled macro should execute. A user can close all of the workbooks but leave the application running and it will be fine. In other words, all the workbooks can be closed but Excel must remain open for the OnTime method to operate.

To call a macro in a closed workbook, you need to supply the full filepath to the workbook. Other than this, it’s exactly the same as scheduling a macro in another workbook:

Important: the workbook will open and try to execute the macro. If security settings are such that the opened workbook is not trusted, the macro cannot run until someone clicks “Enable Macros”. Make sure you set the workbook to be trusted before using this method or you won’t get much automation benefit.

Automation and Recursion

If you run the scheduler once, you will get a single scheduled event. However, if you need to run the macro with the scheduler to schedule it every day, you just shifted the burden from running the macro directly to running the scheduler.

There are times this is useful, like when you cannot determine programmatically when you will need the macro, but you will know before the end of the day and it must be run overnight. In that case, you could run the scheduling macro before you go home only on days you need it.

But if you know your macro will run every day no matter what, you can actually automate the scheduling itself. The best way to do this is write a recursive subroutine, which is a subroutine that calls itself.

There are two common ways to do this: call the scheduler macro from the task macro or roll everything into one and make the scheduler macro the same as the task macro.

First Method
This is a code block using two separate subroutines, which makes breaking them apart easier:

This will run task_sub every day at 5am. Notice how the task_sub macro calls the scheduler macro at the end, which queues up the next execution of the macro for the following morning.

Second Method
This method calls the scheduling method Application.OnTime at the end of the macro, although you can make it the beginning or anywhere in between, if you’d like. The main drawback is you must run the full task every time. It also violates the etiquette of breaking code into more readable chunks with specific purposes. But nevertheless, it works just as well.

Continuity and Canceling

For Application.OnTime to work, the Excel instance in which it was run must remain open. It is possible to open more than one instance of Excel, and that may be useful if you use Excel often and habitually close the main window. If the instance is closed, all scheduled information will be lost — even if Excel is reopened. This is very important to remember.

If you need to run a macro at a certain time each day even if Excel is closed, you’ll have to call the macro from a file, like a .vbs file, and schedule your macro using the Task Scheduler.

There is also the possibility that a scheduled task must be canceled. This can be done by quitting the instance of Excel in which it was created, but doing this will nullify all scheduled tasks. What if you only wanted to cancel one schedule macro? To keep the Excel instance open and schedule a particular task, the exact time and name of the scheduled subroutine must be used. Then the Schedule parameter of the OnTime method should be set to the Boolean False .

This code block has a scheduler macro and a cancellation macro:

To cancel a scheduled task_sub macro, the user can simply run the cancel_macro routine. Notice the positional passing of parameters. If you don’t want to use blank positional arguments like here, use named arguments like this:

Because exact times are important, and sometimes different users might enter different times, you will need to store these scheduled times somewhere. One obvious place is in a cell that won’t be overwritten. Another, but more involved option, is to write the time and macro name variables to a simple text file. A third, even more involved option, is to write custom properties for the workbook in which the scheduler resides. However you do it, it is a good idea to store the times somewhere or risk having to close Excel to cancel a macro you “lost.”

Stability

Automation is great, but only if the code is stable and what you expected to happen actually happens. If your application is meant to run a macro at a certain time every day and you plan to automate it with recursion, it is very important that Excel remains stable. That could mean manual garbage collection, learning about Windows and how the operating system interacts with Excel, and error trapping.

In fact, error trapping is extremely important for rapid automation in VBA. If an application is designed to run every 5 minutes and there is no error trapping, you’re almost guaranteed to come back to a run-time error or useless output. This becomes particularly important when no humans are monitoring the program. Computers won’t fix themselves, so you’ll need a way to alert humans. One way to do this is to send yourself an email once an error is encountered.

Don’t neglect stability and error trapping, especially in unattended automation scenarios. Alert humans to the errors.

Conclusion

Application.OnTime makes scheduling macros easy, as long as Excel remains open. Since scheduling inherently involves some future time, the OnTime method can be called and your macro will run later. This makes recursion easy because the code is not executed immediately like most other VBA macros. That means automation becomes easy, and that’s the point of writing macros, right? It’s certainly one of the most prominent uses of Application.OnTime .

The most important caveats are that 1. Excel, the application, cannot be closed 2. cancelation requests require the exact naming and time used to schedule the task to properly cancel the task. 3. code and macros must be stable for long-term, reliable automation 4. error trapping is not to be dismissed

If you address these caveats satisfactorily, scheduling and automation in Excel using Application.OnTime can open many, many opportunities.

I hope you’ll take a minute to subscribe for more VBA tips. Simply fill out the form below and we’ll share our best time-saving VBA tips.

Ready to do more with VBA?
We put together a giant PDF with over 300 pre-built macros and we want you to have it for free. Enter your email address below and we’ll send you a copy along with our VBA Developer Kit, loaded with VBA tips, tricks and shortcuts.

Before we go, I want to let you know we designed a suite of VBA Cheat Sheets to make it easier for you to write better macros. We included over 200 tips and 140 macro examples so they have everything you need to know to become a better VBA programmer.

This article was written by Cory Sarver, a contributing writer for The VBA Tutorials Blog. Visit him on LinkedIn and his personal page.

Источник

VBA Excel. Метод Application.OnTime

Выполнение процедуры VBA Excel без аргументов в назначенное время или через определенный промежуток времени с помощью метода Application.OnTime.

Синтаксис метода Application.OnTime

Параметры метода Application.OnTime

Основные параметры:

1. EarliestTime – время, когда необходимо выполнить указанную процедуру.
2. Procedure – имя выполняемой процедуры.

Процедура Procedure не должна иметь аргументов и не может быть объявлена в модуле формы.

В качестве аргументов параметра EarliestTime используются следующие функции:

• TimeValue(«hh:mm:ss») – чтобы запланировать выполнение указанной процедуры в определенное время суток.
• Now + TimeValue(«hh:mm:ss») – чтобы запланировать выполнение указанной процедуры по истечении заданного времени с момента запуска процедуры с методом Application.OnTime .

Дополнительные параметры:

1. LatestTime – интервал времени, в течение которого можно запустить указанную процедуру, если Microsoft Excel в назначенное время выполняет другую процедуру. По умолчанию указанная процедура будет запущена в любом случае после завершения предыдущей процедуры. Подробнее об этом читайте на сайте разработчика.
2. Schedule – если задано значение True, будет запланировано выполнение указанной процедуры, False – очистка ранее установленной процедуры. Значение по умолчанию – True.

Параметр LatestTime я не тестировал, а вот любое применение параметра Schedule в значении False у меня в Excel 2016 вызывает ошибку. Поэтому в примерах я эти параметры не использую.

Примеры выполнения процедур по времени

Пример 1
Однократный запуск внешней процедуры через заданный промежуток времени:

Источник