I have an old spreadsheet that used date picker from MSCOMCT2.OCX. Then the computer I used it on died. Unfortunately the Microsoft KB article that has the download for MSCOMCT2.OCX only has a dead link.
My only recourse is to remove the reference to MSCOMCT2.OCX and use other methods to pick the date. I have removed the object from the spreadsheet and all references I can find to it in the code, but when I go to remove it I get an error message stating that the "Can't remove control or reference, in use"
How can I find where it is still being referenced?
Unfortunately the solution seem to be that you have to have to fix the broken link before you remove it. I finally found a copy of the .cab file at archive.org. Once I installed it following these instructions I was able to open my file and remove the reference without issue.
Related
I've created project in VB 2019, was working ok. But due to some problem, I formated my PC & re-installed all the software. Now I realize that path of all the references I used in my project are missing and it shows "The system cannot find the reference specified".
Pls help how to resolve this issue.
You can just remove a reference and then re-add it from the appropriate location. You can do it all from the References page of the project properties or you can remove them in the Solution Explorer first. I'd suggest taking a screenshot first, so that you won't forget any.
I have added my macro to a already existing excel file with macros (build on lower version of excel). It is working fine on my system as well as other systems with same excel version. But when the excel file is opened in other versions, it either crashes or gives error messages like unexpected error occurred(32809)/ compile error. I am using Excel 2010 14.0.7143.500. Can any body tell me how to resolve this issue?
The Telemetry Log displays some simple information about the recorded events. Each record displayed in the Telemetry Log contains a title and lists the severity of the event displayed. For errors, the records also include a description of the error together with steps to address the issue. Keep in mind that not all of the records displayed represent errors caused by Office solutions; the Telemetry Log also shows when solutions and files are loaded or closed successfully.
For example, the issue titled "OM Hidden: Comment.Initial Property" appears if a solution or macro-enabled file opened in Word 2013 attempts to get the initials of a commenter who is associated with a comment. Word 2013 features an improved commenting experience that does not display commenter initials by default. The APIs associated with the older commenting model have been hidden in the Word 2013 object model but remain available for backwards-compatibility. The "OM Hidden: Comment.Initial" issue in the indicates the file that attempted to use the API, the application that raised the event (Word 2013), the time and date of the event, and short description about the error and how to fix it.
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've been trying for a while now to get a reference file to be loaded externally to no avail.
To be specific I am trying to load a "Microsoft Date and Time Picker Control 6.0(SP4)" which usually resides in C:\Windows\System32\MSCOMCT2.OCX
However some people that run a macro containing this element don't have that "MSCOMCT2.OCX" file on their PCs so I thought I will move the MSCOMCT2.OCX to a shared location and reference the code to use the shared one instead (so everyone will have access to it)
I tried doing that but when I was trying to load a reference with "Browse" from a different location it didn't load it - because I already had that in C:..
So I thought OK... I will remove the file from C:\ so I can only reference the shared file. - so I deleted it.
So I open the workbook again and look at references - I cant find "Microsotft Windows Common Controls-2.6.0(SP4)" - great!
And I proceed to add it manually with Browse from the shared drive.
When I do that however 2 references of "Microsotft Windows Common Controls-2.6.0(SP4)" are being added - 1 from C:\(which is not there) and 1 from the shared drive.
The one from C:\ is always automatically selected.
If I try to disable the one from C:\ and enable the one from the shared drive it automatically changes back to what it was when i press OK.
If I try to enable both - it says duplicate References and keeps only the one from C:\
So.. does anybody know how can I get rid of that C:\ reference from the list so it doesn't get loaded? Apparently deleting the files themselves did not work.
Ultimately my goal is to enable people without C:\Windows\System32\MSCOMCT2.OCX file to be able to use my Date Picker Tool.
Thanks a lot!
ActiveX control rereferences are always GUID-based. The VB IDE shows you the current location of the file as listed in the registry on your computer, as a courtesy, but it really doesn't matter what it says. The control will be loaded from wherever it was registered on the user's computer.
That's the key: the control must be registered on the user's computer.
I must strongly discourage you from doing what you're trying to do. You might be able to concoct a method by which you load the DLL from a network location, but it presents no advantage over doing the Right Thing(TM), and plenty of problems. The Right Thing is simply that if you need that control, you must distribute and register it with your application, just like everybody else does. And you really should install it in the recommended location for it (System32); not on the network.
Here's a quick example of what can go wrong: you provide your user with you app, and it works with the control on the network like you want it. Then the user installs another application that happens to need the same control. The app's installer sees that the control is already registered on the user's computer, so it doesn't try to add it again. Except that this particular app is intended to be used when the user is not connected to a network. Now you just broke someone else's program.
The VB/VBA architecture was never intended to support XCOPY deployment. I'm know it's a pain and that these extra steps are extremely inconvenient when you're just trying to deploy a "macro". Sadly, it's the nature of the beast. I'm sorry
Right now we have a program that opens all of the word files in a folder and adds some information to the footer. After switching from Windows XP and Word 2003 to Windows 7 and Word 2007 we have started getting the following error:
Run-time error '5096':
EOALPHABETICARABICARABICABJADARABICALPHABAHTTEXTCAPSCA
(c:\Users...\Content.MSO\8BE508C6.docx)
It occurs at random in any of the files (you can be 10 files in or 100). I thought that it might be a problem with the files being on a network drive so I modified the program to copy each file locally first, add the footer to that copy, and then copy it back out to the network. However, that didn't seem to work. I'm looking for any suggestions on how to fix the problem or possibly rewrite the solution. However, I need to keep the solution in VBA since this app is part of a bigger suite which in not ready for a .NET re-write.
As it turns out I was able to workaround this problem by copying the word files locally, running the main code on the local copies, then copying them back out to the network. It didn't seem to be working at first because the user's machine on which I tested it did not have the most recent version of the program.
Adding this note for those still looking for answers to this error...
I have a macro that creates several docs from one that is open based on sections in the main document.
I was getting the Run-time error '5096' and was an able to find any solutions that worked.
Upon further examination while debugging the code I discovered that while pulling data out of the main doc and building a file name that there was a carriage return after the file name and before the extension. After adding a replace statement to remove carriage returns I am able to process documents all day without an error.
I have found that the error is caused by the total number of characters in the file name is too long. This usually occurs when manipulating file names and the full path is set in the variable. I will manually chop pieces out of real long names to force it to work.
I suppose if I were smart, I'd move into the directory and just deal with the file names without the directory prepended to the name.