I have an Excel addin, developed in VBA, deployed on the network.
The addin reads from an Oracle database, and pastes tables in a new worksheet, which will also contain a button (triangle shape) to refresh the table.
Everything works great, but I must protect code with password.
When i do, the following error appears on some machines:
Compile error in hidden module: Main.
This error commonly occurs when code is incompatible with the version, platform, or architecture of this application.
Although it compiles perfectly when unlocked.
On other machines it requires VBA password on close, even though i have nothing of the sort defined under close event.
I am hoping to secure my code, without running into above problems.
Any suggestions are appreciated.
I know of two situations in which this error occurs:
1: 32bit vs. 64bit issues (already mentioned in the comments). If you've developed a 32bit addin and try to deploy/use it within a 64bit Excel, then your quoted error message will appear.
2: Missing references.
I think the second option is more likely to be the cause of the problem, because usually all client PCs in a company will have the identical version of MS Office installed and this error occurs only on some machines.
So I suggest to check your references. In the VBA-Editor (Alt+F11) go to tools --> references and note down any ticked modules. Then compare this to a client where the error is occuring (go to client PC and repeat the procedure).
If the ticked modules don't match between development and client PC, this is most likely the cause of this issue. You might also encounter modules with a "MISSING" written in front of their name on the client PC. In this case, remove the tick from the missing module and try to execute your addin.
If it works flawlessly you should be good to go, if not you'll have to manually install the missing modules on the clients PC.
Hope this will help you.
Related
I have written a rather complex application in Microsoft Access. It is split into front end and back end files. To protect my code, I have compiled it and saved it as a runtime .accde file, which I then changed to an .accdr file to ensure it operated as a runtime. I have created two versions of the application: one for those with 32-bit Office installed and one for those with 64-bit office. I have used Inno Setup to package the application, the data file, and other files such as the icon file, the license file, etc., into an installable package, which works just fine.
Among my team of 27 beta testers of this application, so far 6 have downloaded it, and I have tested it on four of my own computers. On seven of these computers, the installation works perfectly and the application runs with no problems.
On the computers of three of my testers, when they try to run it, they get this error message:
The expression On Open you entered as the event property setting produced the following error: Bad file name or number.
* The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure].
I'm pretty sure I know where the code is that's causing the problem, but cannot for the life of me figure out why the application crashes on those 2 computers but not on others.
The On Open event I suspect of causing the problem checks the linked tables, gets their connect string, then looks at the path for that string for the back end database. If it does not find it there, the procedure pops up a file selector dialog and instructs the user to find the data file, then it relinks all the tables.
If anyone could point me in the right direction to fixing this problem, I would be extremely grateful.
This is typically caused by a reference labelled as MISSING.
You have two (three) options:
Run the application on the offending machines with a full version of Access that lets you debug the code
Create a small test application that lists and verifies the references you use, and run this on the offending machines
Remove those two customers
Thanks to all the contributors here. Because of these folks and additional online research, the latest answer I can find is this:
This error occurs on a small percentage of computers on which the app is installed, and no one has yet figured out why, what causes it, or how to fix it. The workaround is to install the 2013 version of the Access runtime, as later versions will still cause the problem.
At least one of the offending computers is running the Click-to-Run version of Office. Still gathering information, but that's the status as of now.
I have written some VBA code which works fine on my machine and sent it to someone for testing. When they attempt to run the code on their machine they get an error message stating: "Could not load some objects because they are not available on this machine."
Some research has revealed the likely issue is the fact that I am using a Date Picker object in a userform, which supposedly doesn't work on all versions of excel. However this person is running excel 2010 32 bit just like me, so I don't understand why it wouldn't work.
Is there anything I can do to ensure my code will run on any machine running excel 2010 32 bit? Or do I have to revert to using textboxes D:
thanks for your thoughts.
I am running Windows 8 with Office 2013 (64-Bit). I am trying to continue developments in VBA in Excel that I started with Office 2010 (32-Bit). I am aware of the necessary 64-Bit alterations however I am receiving confusing configuration errors.
Here is the problem:
If I create a new Excel file and VBA project; all my VBA code functions correctly. No problems.
If I open and use a macro from a file that was developed/used in Office 2010 previously, I receive a "File Not Found: VBA6.dll" error message.
Once I start receiving the message, I receive it on all VBA macro's; even the new ones that (not more than 30 seconds) previously worked fine.
If I then re-create a new Excel file and new VBA Project, that individual piece of new code works fine. No problems - until I run code in one of the 'error files'. The fault then spreads into my new developments.
It's as if Excel is getting its references confused but every time I check them (on good or bad files) they are always exactly the same.
Note:
None of my references are missing.
I don't have VBA6.dll on my system; I have VBA7 and the 'Visual Basic for Application' reference refers too 'C:\Windows\SysWOW64\msvbvm60.dll'
There are two other 'Visual basic for Application' references on the list but it wont let me change them
It works on new files without VBA6.dll so I assume it isn't required?
I have checked for and installed all the latest Windows updates.
What should I do to troubleshoot this problem?
If you think I need VBA6.dll, is that because the referenced libraries use it?
If so then why are they not using VBA7?
And why does it work correctly before opening an old VBA6 file? Does Excel suddenly decide all files must use VBA6 just because one file did previously?
Anything to cure me of my confusion is much appreciated,
Best regards
EDIT: I almost forgot to mention;
When I try to debug the error after receiving it, Excel crashes (every time).
I also sent a 'bad file' to a colleague who [with the same system configuration] hasn't yet received this problem - and they also received the error. Suggesting it is something wrong with the files?
EDIT 2:
The problem is not yet resolved. I hope the downvote will not hinder my chances of an answer.
I have also tried re-registering libraries but nothing has changed.
If I open a 'bad file' I can add new Macros and they work fine; but the second I run an existing Macro and receive the error, the new Macros do not work either.
The error was caused during Office 2013 (64-bit) installation. The VBA7 DLL was not registered correctly so I had to open regedit and manually input the correct filepath in both
HKEY_CLASSES_ROOT\TypeLib{000204EF-0000-0000-C000-000000000046}\
6.0\9\win32
4.2\9\win32
Replacing the 'C:\Windows\SysWOW64\msvbvm60.dll' data value (mentioned in the question) for Visual Basic for Applications to the VBA7 DLL filepath. Which on my system is:
C:\Program Files\Common Files\Microsoft Shared\VBA\VBA7.1\VBE7.dll
All files now work; I hope this solves the problem for anyone else in the future.
I am having serious problems with the Microsoft Windows Common Controls 6.0 SP6 library in Access. I have a number of scripts which were working fine before the weekend, but which fail lately on multiple different computers when they encounter the StrConv function. Here's a low-down on what's been going on:
Previously, all was working fine. On the afternoon of Friday the 20th (4 days ago), I began encountering some odd messages when I moused over a progress bar ActiveX control I had on one of my forms. This happened on the MouseMove, MouseDown, MouseUp and MouseClick events at least; the message reported was "The expression [MouseMove] you entered as the event property setting produced the following error: There was an error loading an ActiveX control on one of your forms or reports." I had registered none of the events mentioned on this control. Scripts in general were still working at this point.
Yesterday (after the weekend), I found that scripts I had written no longer worked. When encountering the StrConv function (which I was using to convert a string to uppercase), the VBA editor brought up an error message saying "Compile error: Can't find project or library." This function I'd imagine is quite a core part of the VBA language, but the only missing library I could find under Tools->References was "Microsoft Windows Common Controls 6.0 (SP6)". The missing file was listed as C:\Windows\system32\MSCOMCTL.OCX but this was present on the machine anyway. Browsing to it in the references dialogue made no difference.
Since then I have tried installing various different Microsoft Visual Basic redistributions, have followed the instructions at http://www.fmsinc.com/MicrosoftAccess/controls/mscomctl/, have phoned our company's tech support and have tried a system restore to a point where the scripts functioned previously, but nothing has worked. The database I am using resides in a networked folder on a server but the MS Access applications are local to the workstations.
Is there any way to resolve this issue?
Simply open one of the forms giving you trouble in Design View. Insert a new ActiveX object control in the form and save. Load the forms again. Hopefully this solves the problem. You can then safely delete the added control.
I have run into an odd problem while attempting to register a vendor-supplied ActiveX control on two different computers. On one computer, I can register the part using regsvr32, and then use it in an Access 2007 form with no problems. On the other computer, after I register the same DLL, it is simply not recognized as a valid ActiveX part by Access 2007, or any other Office 2007 program.
The ActiveX part is contained in a single DLL. I am not missing an additional file on one of the computers.
I cross-checked the exact version of the DLL on both computers using md5sum. Both DLL files are exactly identical.
I cross-checked all of the registry entries generated when the part is registered, using the Nirsoft ActiveX Helper utility. The entries are identical.
I checked Access to make sure that the part had a reference entry which pointed to the DLL.
I checked that the location of the DLL was specified as a Trusted Location in Access.
Unfortunately, I am not enough of a COM expert to know whether or not I am overlooking something odvious. Any additional ideas would be appreciated.
OK, total shot in the dark, but we have some computers in our organization the the IT has locked down pretty tight. When we run setup's they run OK and register our ActiveX components, but the first time we run the program it has to be as an administrator. After that the normal user is able to run the program.
You could try a simple VBS script to verify that the control can be created.
Using Notepad (or similar) save the following as test.vbs, and then double click it to run it.
set oTest = CreateObject("<YOUR PROGID HERE>")
MsgBox ("All Done Successfully")
You should get an reasonably descriptive error or "All Done Successfully".
This would at least point to whether its a system wide or Office specific problem.
And if you get an error it may well point to the actual problem.
OTH, if you don't get an error then you probably have an Office installation issue - which could be resolved by a re-install.