I have a macro that runs when an explorer is activated. I discovered that if I put a DoEvents function/statement in the macro, then any time I use another app (say, a browser) and then click back on the main Outlook (i.e., explorer) window title bar, the Outlook window maximizes, as if I had double-clicked on it.
If I comment DoEvents out, the window behaves normally.
This behavior occurs even when DoEvents is the only statement in the Activate macro.
The macro runs as expected when the Activate event occurs, but the window state changes for no apparent reason if DoEvents is present.
Is this a known issue?
Thanks!
==== EDIT =====
If I run the following code in ThisOutlookSession, the strange window behavior occurs:
Private WithEvents my_x As Explorer
Private Sub Application_Startup()
Set my_x = Application.ActiveExplorer
End Sub
Private Sub my_x_Activate()
DoEvents
End Sub
In addition, clicking once on an item in an explorer when Outlook does not have the focus causes the item to open, as if double-clicked. Plus occasional other strange behaviors.
I am using Outlook 2013 in Win10.
There is absolutely no reason to use DoEvents. Ever. You might be stealing some of the Windows messages that Outlook itself expected to handle.
First of all, I'd suggest scanning your machine for viruses.
Then I'd recommend checking the list of running add-ins in Outlook. You may try to turn them off and see how Outlook works after.
There is no need to use the DoEvents in the Activate event handler.
Related
I'm hoping someone on here can point me in the right direction with some expertise. I have a situation with a client's outlook where we need to close any open draft windows after a new message/draft is opened. Ideally after the 4th new window has opened.
Any "new message" window that opens after this we need the script to close 1st window that opened. Either killing the process, or something similar.
Recently have been looking into Outlook macros, but am unsure if they will help in this instance. (Maybe they are?). Being more familiar with Powershell, figured we could start there.
Looking to get help writing a powershell script, macro, etc to do this on the backend.
The Outlook object model provides all the required events, methods and properties for that. So, VBA macros is the right choice if you don't need to distribute the solution on multiple machines. Otherwise, you need to consider developing a COM add-in instead (for example, a VSTO based one should work for you). See Walkthrough: Create your first VSTO Add-in for Outlook for more information.
You can handle the NewInspector event which is fired whenever a new inspector window is opened, either as a result of user action or through program code. The event occurs after the new Inspector object is created but before the inspector window appears.
You can also check the number of opened inspector windows in Outlook by using the Inspectors.Count property which returns a long indicating the count of objects in the specified collection.
Finally, the Inspector.Close method closes the Inspector and optionally saves changes to the displayed Outlook item. For example, a VBA sample which closes the active inspector instance:
Sub CloseItem()
Dim myinspector As Outlook.Inspector
Dim myItem As Outlook.MailItem
Set myinspector = Application.ActiveInspector
Set myItem = myinspector.CurrentItem
myItem.Close olSave
End Sub
Using Outlook 365.
I needed code to bring Outlook reminders to the front of all other windows. I found this code on the Extend Office website, and entered it into the ThisOutlookSession module:
Private Sub Application_Reminder(ByVal Item As Object)
'Updated by ExtendOffice 20180814
Dim xAppointment As AppointmentItem
If Item.Class = olAppointment Then
Set xAppointment = Item
MsgBox xAppointment.Subject, 4096 + vbInformation + vbOKOnly, "Outlook reminders"
End If
End Sub
Last week, it worked fine; whenever a reminder fired, I'd see a Msgbox reiterate its message.
This week, I realized that the Msgbox was no longer popping up. I believe my computer had restarted over the weekend, but that's the only change I can think of. I've tried trapping the code with breakpoints, and as near as I can tell, it's just not running.
I'm not familiar with "ThisOutlookSession", but just to be safe I tried restarting Outlook, and it didn't help. I use two different Desktops in Windows, and I tried running Outlook on each, but that didn't seem to matter.
First of all, you need to check the Trust Center settings in Outlook whether VBA macros are allowed to run. Then try to enable macros in Outlook by following:
"File"->"Options"->"Trust Center"->"Trust Center Settings..."->"Macro Settings"->"Enable all macros"
You may find similar issues posted in the Outlook Not Running Visual Basic After Restart and VB Macro runs successfully at first, but fails after Outlook restart posts.
Basically I am using below code to run macro after I manually open a specific email.
The code and macro works ,but I noticed there is a slowness while opening of any email on outlook.
After many tests, I find out this line is the cause of issue:
Set MyItem = Item
And this the full code:
Option Explicit
Option Compare Text
Public WithEvents MyItem As Outlook.MailItem
Private Sub Application_ItemLoad(ByVal Item As Object)
If Item.Class = olMail Then
Set MyItem = Item 'This line cause slow opening of any email
End If
End Sub
Private Sub myItem_Open(Cancel As Boolean)
If MyItem.Subject = "Test Email" Then
'Code
End If
End Sub
Kindly How to fix this issue?
Basically I am using below code to run macro after I manually open a specific email.
You may consider using other event handlers in Outlook - for selecting in the Explorer window you may try to handle the SelectionChange event of the Explorer class which is fired when the user selects a different or additional Microsoft Outlook item programmatically or by interacting with the user interface. For opening in the separate window you can handle the NewInspector event which is fired whenever a new inspector window is opened, either as a result of user action or through program code. The event occurs after the new Inspector object is created but before the inspector window appears. Also you may handle the Inspector.Activate event which is fired when an inspector becomes the active window, either as a result of user action or through program code.
If there is a specific reason to use the ItemLoad event handler in the code you may continue using the late-binding technology and keep the item defined as object.
Also don't forget to release corresponding objects in the Unload event of the Item-level events.
I currently have a form with a couple of buttons, text boxes and a AcroPDF. AcroPDF is an additional control I have added to my toolbox and I get it from "Adobe PDF Reader".
This macro is being used on various computers and I have found out that, for some reason, the macro does not work on all computers. But when I delete the AcroPDF control from the form, it works for all computers. For the computers that do get an error, it happens when I first open the file I automatically get an error msg and the form does not automatically show up (like how I programmed it to).
Is there a way I can program this into my "Thisworkbook.open" so that if there is an error, I can somehow delete or disable this additional control? something similar to how you are able to turn on and off references? (see below)
ThisWorkbook.VBProject.References.AddFromFile ("libraryName")
UPDATED: the error message I get from the computers that don't work is the following:
system error &H80004005 (-2147467259). unspecified error
Thanks.
UserForm.Controls.Remove -- but this only works for controls added at runtime (dynamically). You cannot use the Remove method on a control that was added from the Designer.
Probably you need to reverse this logic, and only add the control when the reference exists on the user's machine.
Dim ctrl
If Len(Dir("libraryname")) <> 0 Then
Set ctrl = UserForm1.Controls.Add ...
End If
You would also then want to use the Remove method when closing the form, that way the form remains in a state that could be opened on either computer.
HOWEVER, the error message you get on the other machines may shed additional light on the source of the problem. Depending on what the error is, there may be other solutions that don't involve removing the control.
If you don't mind creating a duplicate form without the AcroPDF control you might be able to use labels and the GoTo statement.
Sub Workbook_Open()
' do stuff
On Error GoTo AcroPDFError
ThisWorkbook.VBProject.References.AddFromFile ("libraryName")
' load your form with the AcroPDF control here.
Continue:
On Error GoTo 0
' the rest of your Workbook_Open sub is here
Exit Sub
AcroPDFError:
' load your form without the AcroPDF control here.
GoTo Continue
End Sub
In 2003 the workbook would just close. But now the same code is re-opening the workbook. There are some lines afterwards and then the sub ends. When the sub ends, the workbook_open event gets fired for the closed workbook, even though there is no code that opens any workbooks. The debugger is almost useless, it is not reproducing the bug if I execute everything step by step, in fact everything works fine when I use the debugger.
I use
ActiveWorkbook.Close False
For closing the workbook (from an add-in).
Help much appreciated.
I added a slight amount of code for Excel 2007 because of the annoying ribbon and Microsoft getting rid of custom menus. To somewhat compensate for this, I wanted to have the add-ins tab in the ribbon always visible for convenience, but I was using Application.OnTime and sendkeys to do it (because Microsoft didn't bother including an API with the stupid ribbon...). Well OnTime seems to have been the root of my troubles.
Figured out how to get both. Workbook_beforeclose cancels the scheduled ontime event by calling:
Application.OnTime EarliestTime:=Now(), Procedure:="Name", Schedule:=False
but otherwise the ontime event gets executed.
If the event does not get cancelled before beforeclose is called, the workbook will close then re-open to run the scheduled ontime event (because the workbook is opened so briefly that ontime doesn't get a chance to run before I need to close it).