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.
Related
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 am about to create a VB.NET Application that is able to automatically format Word documents or change specifical things in it. But the applications stops regularly working because Word (working in Background, not visible) opens popup Dialogs, e.g. if the document is a .odt file, or was downloaded from the internet, or even the "Save File" dialog.
Is there any possibilty to prevent Word from opening any of these dialogs?
I haven't found anything in the MSDN Developer Reference concerning this subject either.
Does anybody have an idea how to do this? Thanks in advance.
I haven't done this with Microsoft Word, but I have done something similar in doing COM automation with Microsoft Project from .NET. Below is the code fragment that turns off all sorts of annoying pop-ups from MS Project:
mApp.DisplayAlerts = False
where mApp is Microsoft.Office.Interop.MSProject.Application
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.
Why would a .sln solution file open and appear empty in Microsoft Visual Basic 2010 Express - i.e. no windows showing projects and code files etc.
When I inspect the file in a text editor, it contains references to vbproj files (which are present) which indicate that it should not appear as empty.
No error messages are reported when the file is opened.
Update:
(To illustrate my problem)
It attempts to load the projects that belong to the solution:
And then results in a bare solution screen
Express Edition is limited to on project per solution. If you have more than that, you will not be able to use the solution file with the express edition of visual studio. You will need to open the projects separately.
The answer is that the projects did load for the solution but the Window to display them was not open or visible. To make it visible, go to the View menu and select Other Windows:
This displays the 4 projects referenced by the solution
Forgive me for blurring the project names but this might be commercially sensitive and therefore not for public awareness. But you get the picture.
In summary it was my lack of knowledge about the tool, though I had looked under the Window option first thinking along these lines, but the View menu is actually where one would go to display things about the project.
Thanks to everyone for your contributions.
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.