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.
Related
I am trying to help a small company that is using an .mdb database in Access 2007. Their previous programmer left little documentation, unfortunately. The problem occurs when they call some routines that are intended to create a PDF file from an Access report. The routines were written by Stephen Lebans, and are supposed to be safe and stable. The Lebans routines are called by VBA code.
Here is some more info. The company has a small network with two workstations. On one workstation everything works fine; it is able to call the Lebans routines and create a PDF file. On the second workstation the code appears to execute but no PDF is created. Adobe Acrobat DC was installed recently on both PCs. The problem creating PDF files on PC#2 began after they installed Acrobat DC.
I will probably call Adobe tech support to get their help. But before that I hope someone can help with several questions I have.
Question 1 - In the VBA editor, in Tools -> References, I see that "AcrobatPDFMakerForOffice"
is checked. Please let me know if I should have checked some other reference instead.
Question 2 - The "AcrobatPDFMakerForOffice" in Tools - > References seems to refer to the following file: "c:\Program Files (x86)\Adobe\Acrobat 2015\PDFMaker\Office\AcrobatPDFMakerForOffice.tlb" ,
which is a type library file. Does that seem OK? Or should it point to a "dll" or "exe"?
Question 3 - On PC#1, which is creating PDFs correctly, if I click the Office button inside Access,
select Access Options, then select Add-Ins, I see "Acrobat PDFMaker Office COM Addin" under the heading "Active Application Add-Ins". And the file it refers to is:
"c:\Program Files (x86)\Adobe\Acrobat 2015\PDFMaker\Office\PDFMOfficeAddin.dll".
On PC#2, however, there is nothing listed under "Active Application Add-Ins". So I attempted to add it.
I clicked "Go" next to "Manage COM Add-Ins" at the bottom of the screen; then clicked "Add..." in the
"COM Add-Ins" window that appeared; then navigated to the file "c:\Program Files (x86)\Adobe\Acrobat 2015\PDFMaker\Office\PDFMOfficeAddin.dll"; then click "Add". But nothing appeared under the heading "Active Application Add-Ins".
Any thoughts on how I can add "PDFMOfficeAddin.dll" to the Active Add-Ins list; or if I need to at all?
Thank you!
Cross Posted Here https://www.access-programmers.co.uk/forums/showthread.php?t=295390
As pointed out in that post Access can create a PDF natively now. There is no need of the Lebans code.
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 have a word document that has a few userforms and options to auto create an entire document. It works great on all of the installations I have tried from 2007 to 2013. The problem is that one user on one computer gets compile errors when it the user form is launched. The compiler complains that controls do not exist that actually DO IN FACT exist. I had him create a temporary account, just a simple test account, no admin permissions and it runs fine.
I have have tried killing the usual suspects
-.dotm files
- normal.dot files
- wiped word start up folders
- I have reset the word registry key
- I have renamed the appdata\Microsoft\office, appdata\Microsoft\word etc etc etc.
There are no missing references.
More oddities:
it complains about a missing control, lets just say frm.txtname.
I cut the sub that contains the reference and paste it at the bottom POOF it no longer believes the control is missing but...it finds another one to complain about.
I know it is something wonked up in the profile but I cannot find it.
Try this: In VBA editor open Tool bar and click References. You will see the list of references. Unclick those who starts with "MISSING". It should work.
I was having requirement to run the Macro when we open the document. For that purpose i have created .Dotm template with AutoOpen method. Problem is it doesn't execute. When i add the AutoOpen macro in Normal file it works perfectly.
We don't want to add the AUtoOpen code in Normal.dotm file. How can we achieve the same using different Template file.
I had exactly the same problem. I had 2 separate .dotms with AutoOpen modules that were not auto opening on XP or Win7 x64 both with Office 2010. I subsequently noticed that all my Subs in the AutoOpen module were Private. Hmmmmm. Made my Main Sub Public, left all other Subs Private, and both of them now AutoOpen. Maybe this will help.
"For that purpose i have created .Dotm template with AutoOpen method."
Create new documents with this NotNormalWithAutoOpenMethod.Dotm with File | New.
For an existing document, create a new document based on NotNormalWithAutoOpenMethod.Dotm. Copy the contents of the existing document into the new blank document. Save and Close. Upon reopening the new document, the code should run.
Wasn't me, but I'm guessing you got downvoted because you haven't said what you've tried, what version of Word you're using, or what OS you're on. All of those things are useful in diagnosing the issue.
I'm also guessing that you can not simply save the macro to whatever document you want to run it in, because that should be trivial. Am I correct?
If so, I am trying to do something very similar using Word 2010 on Windows 7 64-bit, but I can't get it to work yet either. The document I need to open is auto-generated from pandoc and is opened in compatibility mode, so perhaps that's my issue. If that's not the case for you, some of the things I've tried might help you.
Use the /t option from the command line: start winword /tmacros.dotm document.docx
If that doesn't work, try adding the /m option as well: start winword /tmacros.dotm /mAutoOpen document.docx.
Instead of naming the macro AutoOpen, try AutoExec or Document_Open.
Note: there is no space between the /t or /m options and the filenames. I've also tried the full path to winword.exe instead of start winword but that didn't make a difference.
Hope this helps, good luck! And please post the solution back here if you figure it out on your own.
Sources:
Command line switch: http://support.microsoft.com/kb/290961
AutoExec/AutoOpen: http://support.microsoft.com/kb/286310
I have a VBA macro which runs in Word 2003. It is one module and the code attached to a userform, and it goes to about 30 client sites. When I first rolled this out I sent someone round to each site to place a .dot template in the Word Startup folder of each of 30 boxes, which then makes the macro appear as a button on the toolbar for each user.
All the users are internet connected.
The location of the .dot template varies from machine to machine, so "installers" would be out of play I presume?
I am anticipating that the macro made need to change from time to time. Is there any way I could get the user to press a button to get the macro to update itself?
Whether its push button or auto run checking for update, I would presumably need to know how to determine where the macro is running from (path) without a document necessarily having been saved, and how to find path to the Startup folder tools>options>file locations but programatically .
This can be done.
create 2 .dot files, loader.dot (checks for updates) and worker.dot (the main macro you are using and want to be able to update automatically).
the first loader.dot should go into C:\Program Files\Microsoft Office\OFFICE11\STARTUP
This is a trusted location and the macro will be loaded into any Word document. Use an AutoExec() subroutine to ensure it runs whenever a word doc is loaded.
worker.dot can go in any fixed installation location e.g. C:\yourapp\worker.dot
The logic in loader.dot is remove any reference to worker.dot (I had to enable trust of VBA model in macro security settings) check for an update using an http call, if new version available download it overwriting worker.dot, then add reference from file specifying worker.dot
I'm not sure that the user-presses-a-button model is ideal.
I'd look into building a "loader" template. Its job would be to run at startup and look for updates to the template/macro you already have and download/install/whatever such files when they change. Then load whatever's installed locally for use.
You should also think about whether it's a problem if an update is available but someone doesn't use it (perhaps they started Word before the change was uploaded, or they're offline). Also, do you need to know what version people are using? Have your loader report back, via HTTP, email or some other method (Twitter?)
Any such loader needs to either very stable (otherwise you just replace chasing around replacing the target template with chasing around replacing the loader) or able to update itself when necessary.