Hi all,
Apologies, but there may be two parts to this question..
In Outlook 2010, I cobbled together a macro from a series of code snippets and some of my own volition, and everything "works" (subjective term).
Basically the macro constructs a calendar and adds appointments from a group of users calendars who've tagged selected appointments with a certain category. I don't have issues with the macro itself (at least I don't think so...), my questions are relating to running this macro at start-up, and possibly about some changes between Outlook 2010 and 2016.
First, running the macro from the Outlook VB editor, the code takes ~9 seconds to run (Timer calls at start and end). This is about the same for Office 2010 and 2016.
I have also configured the macro to run on Application_Startup() -- well in a round about way from code I must admit I don't quite fully understand all the mechanics/implications of:
And then I have a Class module:
And another module with the actual makeGroupCalendar() code.
I forget why I went/needed to go this SyncObject route - I think it was something about making sure I had fully connected to the exchange server before trying to access members calendars. But, the end result is what I want, the macro is ran automatically on start-up and builds the calendar.
However, looking at the VBE Immediate Window after start-up, the macro takes ~25 seconds to run. I get that on start-up there are probably lots of things that need to happen, and the code has DoEvents within the loop to keep Outlook 'responsive' while the macro is running.
Now, in Outlook 2010, this wasn't such an issue, the DoEvents seemed to 'do their job' and Outlook was still responsive (a little laggy, but usable while macro ran). In Outlook 2016, it is unworkable. It's as if the DoEvents aren't honored, and the entire Outlook locks-up for the 25 seconds while the macro runs.
So, has anything changed in the use of DoEvents between 2010 and 2016? Can anyone suggest a reason why code that runs in ~9 seconds manually after start-up takes ~25 seconds on start-up?
Cheers
Apologies, but there may be two parts to this question..
In Outlook 2010, I cobbled together a macro from a series of code snippets and some of my own volition, and everything "works" (subjective term).
Basically the macro constructs a calendar and adds appointments from a group of users calendars who've tagged selected appointments with a certain category. I don't have issues with the macro itself (at least I don't think so...), my questions are relating to running this macro at start-up, and possibly about some changes between Outlook 2010 and 2016.
First, running the macro from the Outlook VB editor, the code takes ~9 seconds to run (Timer calls at start and end). This is about the same for Office 2010 and 2016.
I have also configured the macro to run on Application_Startup() -- well in a round about way from code I must admit I don't quite fully understand all the mechanics/implications of:
Rich (BB code):
Private Sub Application_Startup()
Debug.Print ("Starting Handler: " & Time)
mySyncInstance.Initialize_handler
End Sub
And then I have a Class module:
Rich (BB code):
Sub Initialize_handler()
Set mySync = Application.Session.SyncObjects.Item(1)
mySync.Start
End Sub
Private Sub mySync_SyncEnd()
Call makeGroupCalendar
End Sub
And another module with the actual makeGroupCalendar() code.
I forget why I went/needed to go this SyncObject route - I think it was something about making sure I had fully connected to the exchange server before trying to access members calendars. But, the end result is what I want, the macro is ran automatically on start-up and builds the calendar.
However, looking at the VBE Immediate Window after start-up, the macro takes ~25 seconds to run. I get that on start-up there are probably lots of things that need to happen, and the code has DoEvents within the loop to keep Outlook 'responsive' while the macro is running.
Now, in Outlook 2010, this wasn't such an issue, the DoEvents seemed to 'do their job' and Outlook was still responsive (a little laggy, but usable while macro ran). In Outlook 2016, it is unworkable. It's as if the DoEvents aren't honored, and the entire Outlook locks-up for the 25 seconds while the macro runs.
So, has anything changed in the use of DoEvents between 2010 and 2016? Can anyone suggest a reason why code that runs in ~9 seconds manually after start-up takes ~25 seconds on start-up?
Cheers