I have some rules for work in outlook 2013 - however following my laptop crashing the other day, I can no longer run any rules, they simply do not work (I don't even get a debug notification). Upon checking my macros, I found that when I tried to click on any scripts I have and I keep getting the message 'This action is not available in the current mode'.
The option to create a new script has disappeared from the rule list too.
So far I have tried:
-Using the outlook 2016 fix by running the registry fix DWORD 1 (There is nothing out there for 2013). I have restarted my Pc and it still has not changed a thing.
-System restore to a previous date. This has literally changed nothing.
I'm a little stuck. I have attached screenshots to further explain exactly what I am experiencing.
Thanks,
Rachael
Some information has been whited out due to confidentiality.
Trust Centre Settings:
I encountered this issue after a Windows Update. Here's what fixed it for me:
Save everything below the line as a .reg file and then double-click it to run and launch (or manually add it your registry via regedit).
You should probably backup your registry first to be safe and please note that this was the correct location for my Office 2013 installation (yours may be different).
Office 2013 = 15.0
Office 2016 = 16.0
Save using Notepad as a .reg file to double-click and upload to your system's registry (Office 2013). I hope this helps someone else! -Mike
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Security]
"EnableUnsafeClientMailRules"=dword:00000001
here is a quick and dirty test to check whether vba code runs at all when email arrives
put it into "ThisOutLookSession" which is under "Microsoft Office Outlook Objects"
then send yourself an email ... if vba runs then you should see a popup
it will not solve your problem, but it will provide more info to help narrow down the cause
Private Sub Application_NewMailEx(ByVal EntryIDCollection As String)
MsgBox "you have mail"
End Sub
Or you can create .reg file Open Notepad and save-as .reg
Outlook 2010
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\14.0\Outlook\Security]
"EnableUnsafeClientMailRules"=dword:00000001
For Outlook 2013 use \Office\15.0\ and Outlook 2016 \Office\16.0\
Related
Do not have enough reputation to comment on the answer by "Aleksey Malov" to query at un-highlighting text.
Preconditions: PowerPoint 2019 or 365. Presentation must be opened with window.
Original shape with highlight:
I'm opening a new PPT file from the VSTO plugin by saving a copy of original PPT file and then performing the following operations on selected shape object. I'm trying to do this using PowerPoint VSTO plugin with Office 2019. This works for me during debugging through Visual Studio but not through the installed plugin.
if(Application.CommandBars.GetEnabledMso("TextHighlightColorPickerLicensed"))
Application.CommandBars.ExecuteMso ("TextHighlightColorPickerLicensed")
My queries:
What does "Presentation must be opened with window." mean?
Why does it not work in the installed plugin?
If I attach the running PowerPoint process in Visual Studio even with Release config, I get expected result where highlight is removed. Any reasons why?
What does "Presentation must be opened with window." mean?
In the code you are relying on the CommandBars object which may not exist until the window is created. To get the code running correctly a window must be initialized.
Why does it not work in the installed plugin?
Well, you need to add some logging statements to see why YOUR code fails. Only looking at the log files you may find any difference.
If I attach the running PowerPoint process in Visual Studio even with Release config, I get expected result where highlight is removed. Any reasons why?
There can be multiple reasons. One of them is that VS could be run with admin privileges which causes all child processes to be run under the same security context. Files may not be accessible without admin privileges and etc.
I have an issue I'm struggling with, and it bothers me to no end. However, I can't come up with a decent solution, so I'm turning to you folks for advice.
The problem is as follows:
I have a .xlsm file containing a few macros. The macros use Forms, and specifically they also use TreeView objects in them (through mscomctl.ocx). I have gone through the Trust Center, and set every setting to it's unsafest form (allow all ActiveX, allow all VBA, no 'safe mode' for web documents, etc etc...
I can open the file, but when I call the macro relying on forms, I get a warning message labeled 'Microsoft Forms', with the following error message:
This application is about to initialize ActiveX Controls that might be
unsafe. If you trust the source of this document, select Yes and the
control will be initialized using your document settings.
It both surprises me (I said to allow it all in the settings, didn't I?) and annoys me (well, not the first time, but me and my coworkers use it on a daily basis and it gets on my nerves).
Does anyone have a clue whatsoever as to:
1) Why this happens?
2) How I can avoid the message?
I'm open to both solutions on altering the Excel file, or settings I have to alter on local machines (<20 PC's).
Details:
Windows 8.1, running Excel 2013. The macro-code is 'safe', it's built by our company employees (myself included). Code is password-protected so can't be meddled with.
Try the below steps
1) Launch Excel
2) Click "File - Options"
3) Click "Trust Center"
4) Select "ActiveX Settings"
5) Modify "ActiveX Settings for all Office Applications" from the default ("Prompt me..." - see above) to "Disable all controls without notification"
We see same error in an Excel solution with a TreeView form-component on 64-bit Win7 and solution here is to re-register mscomctl.ocx
Bat-file code:
regsvr32 /U "C:\Windows\SysWOW64\MSCOMCTL.OCX"
regsvr32 /S "C:\Windows\SysWOW64\MSCOMCTL.OCX"
Regards
I developed a program in Word and Excel version 2010 using VBA. Within the VB IDE I created a form for which I added a ListView control to. In order to do this I had to open the tools window, right click on it, and select ListView as a component. It then became available to add as a component. It is using the MSCOMCTL.OCX. It functions perfectly on my device, but when I execute the program on another computer, the code raises an object error on the first line that addresses my ListView control:
Run-time error '424'
Object Required
With lvwLog
.ListItems.Clear <--- Error occurs here
.ColumnHeaders.Clear
All the computers in my company are configured/imaged the same way. All are using the same version of office, using Windows 7 Enterprise, and all will have the ListView 6.0 under the component's menu, just not selected. If I were to go into the IDE on the "foreign" computer and open up the form in design, the ListView is not there. You can probably guess that when I add it and name it the same as how my code is addressing it, this will then work on the other computer as designed.
There is no package and deployment wizard available in the Office version of the IDE, and even though I can probably find this, my end users will not go through the process of "installing" an Excel or Word document. If I can't find a way to get this control to register programmatically, then this application I wrote is just not going to get acceptance.
Though we have very few 64bit versions of Office, a different error is raised if opened on a device running the 64bit version of 2010:
System Error: &H80040111 (-2147221231). ClassFactory cannot supply selected class. This appears to be related to the same error, as it errors on the same line of the ListView code. Not sure if once I fix the above if I will need to re-write it in a 64bit version of Office.
Note: "Moving to another computer" simply consists of copying the DOCM or XLTM file to the device and opening it.
After further research I determined that the MSCOMCTL.OCX in the C:\Windows\System32 sub directory on my device was a much newer version than the OCX on the devices in which the code was failing on. This OCX is directly related to the ListView component I was adding to the form.
Once I copied the later version of MSCOMCTL.OCX (version 6.1.98.39, file date 3/31/2014) then the program ran and loaded the ListView control with no errors. Something else I will note is it is not necessary to re-register the OCX if it is being copied to the same system directory and with the same name. Simply copying to the system folder and overwriting the older file will suffice.
I am trying to switch a Excel VBA macro from Windows XP to Windows 7. Both of the Windows versions are 32-bit operating systems. My Windows 7 version is Enterprise edition.
The VBA code works fine on Windows XP. When I have tried to run the code on Windows 7, it crashes and reports no error description.
I have registered msinet.ocx, which appears to be required for Microsoft Internet Transfer Control 6.0. I have also tried to fix security issues by adding the additional com components tabctl32, comctl332/232/32 and comdlg32, all of which are ocx files. However, nothing changes - my code still fails on Windows 7.
Once msinet was unregistered, Excel VBA opens my Workbook, reports the missing reference msinet and does not work at all. How do I resolve this issue?
Awkward. Open the sheet in an Excel session with Macro Security set to high or medium, and reply 'No' to the dialogue about enabling VBA macros in the sheet.
If it opens, you should still be able to view the project, and this might show an obvious missing reference or an error if you attempt to compile it.
Next: save the workbook as html and close Excel. Clear the temp folder, restart excel, open the html file and save it back into Excel format. If you're lucky, all the legacy objects and references will be cleared out and replaced by versions compatible with your new OS.
This works about half the time.
The system not crashing when msinet.ocx is not registered doesnt necessary means that it is the problem.
If you have a call to that library (msinet.ocx) in any procedure inside of or called from the ThisWorkbook module and you have that library unregistered, then when the file opens and tries to run the On open macro the module will not compile and therefore wont run the line of code that makes it crash. (I am only guessing that this might be your case.)
Try to find out which exact call makes your system crash.
Let msinet.ocx registered.
Open the file without activating the macros.
Then manually run Step by Step (F8) through the opening code of your file ( Private Sub Workbook_Open() )
Eventually you will reach the exact line of code that makes your system crash. Whit that information you will be able to get more help.
NOTE:
To open the file without activating the macros you can use one of the following methods:
Press and keep pressed the Shift key after you doubleclicked on the file to open it(from the windows explorer). For this method to work, the Excel application must be clossed.
If the Excel application is open, then go to the VB editor and type application.EnableEvents=False in the immediate window (and press enter to run it). Just be aware that this will disable the events on every file in that instance of Excel. You will have to set it back to true or close the application (not just the file).
Check if you don't have references to missing libraries, if so simply uncheck it. I had a similar problem and it helped in my case.
I had a VBA project in outlook with a few email macros - but after a PC crash they are all gone and all I see is a fresh 'Project1' when I hit Alt+F11
I'm not a VBA programmer, but had a collection of handy macros for email sorting etc. I would not like to have to code them again. Anyone know where the code files should be on the filesystem so that I might rescue the code?
This page has some really good insight on where Outlook keeps all its stuff. It suggests the following:
All Outlook macros are stored in a single file named VbaProject.otm in the user's %appdata%\Microsoft\Outlook folder, which will be a hidden folder on most systems.
Now, the problem is that if you do not see them now, then you probably won't be able to restore them from that location: there is probably either an "empty" project there or no project at all, but if that folder is being backed up, you might be able to restore it.
Moving forward, you might consider exporting your macros periodically in case this happens again, either through the VBA IDE (right-click and select Export File...) or using one of the tools mentioned in the linked article (like the Office Profile Wizard).
Ok. things to try to fix this...
I assume after the problem occured you tried logging back into the same windows user account, and the same Outlook profile.
Create a new windows login to the machine in question.
Login to this account and open Outlook, this will create a new outlook profile. make note of the profile name (to find this: Control Panel > Mail applet > Show Profiles...)
Now Exit Outlook, and make sure it is not running (check for outlook.exe in task manager).
Open Windows Explorer.
Copy (don't cut) the existing VbaProject.OTM file. (if it has any other name than that, first rename it to VbaProject.OTM, then copy).
Navigate to C:\Documents and Settings\USERNAME\Application Data\Microsoft\Outlook
(or use the environment variable notation %appdata%\Microsoft\Outlook for vista/win7)
Rename the existing VbaProject.OTM to VbaProject.OTM.OLD
Paste the VbaProject.OTM from step 5 into this folder.
Reopen Outlook and test (i.e. Alt + F11).
Good luck with recovery.
If this doesn't work do you remember adding self signing certificate at all? If so have you got a copy of the cert? you can try reinstalling it into the certificate manager (certmgr.msc)
copy/install it to the Certficiates - Current User\Personal\Certificates hive.
I just found this note from Sue Mosher (outlook VBA guru):
"AFAIK, once an .otm file is corrupted, it can't be recovered. That's why I recommend that people who rely on VBA code export their modules or backup the entire file. "
All macros are embedded into an OTM file, under the following location:
C:\Users\(***Your User Name***)\AppData\Roaming\Microsoft\Outlook\VbaProject.OTM
To restore, replace this file with the older one, it should work
Ran into this same problem.
First reviewed the .otm file mentioned by #Anonymous Type and #Dave DuPlantis
Not corrupted... hmm
I checked my Ribbon in Outlook for the Developer tab. It was missing and simply re-adding it to my Ribbon fixed my problem.