I have observed that below line of code works on one machine but not on other even though both machines have same office 2007 versions.
strName = folderObj.Name
But when I convert property from '.Name' to '.name' then it is observed to be working on machine on which it was not working earlier. Below are some of sample code lines for which I am encountering issues. Per my observation where ever earlier I mentioned .Name is failing on another machine:
strName = folderObj.Name
Application.ActiveWorkbook.Name
Is there any setting which we may need to perform to ignore case for .name.
I remember dealing with a very similar issue a while back, but can't remember the specifics. I want say look for any references in your code to variables, properties, etc that are named 'name' (lower case) and change them to 'Name' (pascal case). I have a vague memory of VBA getting confused when you use different casing for items of the same name. (For the lack of a more technical explanation.) I know this doesn't really address the fact that it runs on one computer but not another, but it's worth a look.
Btw, when you say "it's not working" what error are you getting?
Related
First, apologies for the generic title - if anyone can suggest a better one, I'd be happy to change it, but right now, I have no clue where to start.
I have a workbook utilizing a DLL to access a data provider (Bloomberg), and the requirements to get it to work correctly are quite tricky. Furthermore, deployment is a nightmare, since users might need to reference the DLL themselves.
Naturally, I first check wether the library is referenced, before testing the library itself.
Here's my code (which is working as intended) :
Public Sub TestBloomberg()
Dim ref As Object
Dim fRef As Boolean
fRef = False
For Each ref In ThisWorkbook.VBProject.References
If ref.GUID = "{4AC751C2-BB10-4702-BB05-791D93BB461C}" Then
If Not ref.IsBroken Then
fRef = True
End If
End If
Next
If fRef Then
' In separate Sub to get around User-defined type error
Call TestBloombergConnection
ElseIf Not fRef Then
' warn user about missing reference
End If
End Sub
As you can see, if the reference to the DLL is set, I proceed checking if the library works as intended (this has a lot of external factors at play, such as wether the server-application is running, the user is logged in, etc.) You can think of this as a simple ON-ERROR-GOTO-wrapped call to the dll.
I am forced to move the actual test of the functionality to another sub, as called from the second if-block. If I have no (or a broken) reference to the dll, even though the library will not be called itself, I will get a User-defined Error. If I move the exact same code to another sub, it will work perfectly.
Finally, my question:
What happens when I run my VBA code, why do I get a (i think) runtime error during compile time? How can my code be so dependend on external factors, that it can't even get to the point of failing?
What this behavior demonstrates is that VBA compiles separate subroutines separately and at different times. I had a similar situation when I was trying to resolve references on behalf of the users (solving a versioning problem, which I got to work, but then abandoned as not worth the trouble).
When you are ready to enter a subroutine, it interprets only as much as it needs to, and you could get a compile time error then, even though to you it seems like you are at run time.
The error you are actually getting is probably a 429 Automation error or something similar. You would get that if you have a broken link (dll moved, deleted, or not registered). What I remember from my project, is that I could reliably handle it if a good reference was saved in the file, or no reference was saved, but if a bad reference was saved, the code had to be isolated similar to what you found. I think I had mine in a separate class, but the principle is the same.
I think this "interpret only as much as necessary" is considered a feature of VBA. You can run a certain section of code, even if you have compile errors elsewhere. This can be useful when you only have a partially written functions or other half-finished stuff, or if you open the file on a computer without some referenced software installed. It lets at least some of the functionality still work.
I'm getting a strange behavior from the Office VBA Editor: certain terms no longer capitalize when they are recognized. In fact, I can use the autoselect to choose the term, which is properly capitalized until the compiler validates the line and the editor actually changes it to lower case.
For example, today I typed this Set wFramework = application.ActiveWorkbook using the auto-select to choose .ActiveWorkbook, but as soon as I pressed [Enter], the compiler changed it to Set wFramework = Application.activeworkbook. Notice that the compiler properly capitalized Application but improperly removed the capitalization from .activeworkbook.
For now the number of objects / methods that don't capitalize correctly is small, but seems to be growing.
I've tried things like turning off all the code settings in hopes this would somehow reset things, but that was a non-starter. I can't find anywhere with controls for that function. I wondered if this is handled through the References, but there doesn't seem to be anyway those should be editable, especially without my doing it on purpose. I'm also wondering if this is somehow a function of Windows improperly tracking case management, but again it seems like that would be specific to a Windows session, and this symptom persists even if I have shut down the computer completely and restarted.
Does anyone know what might cause this, and whether it is possible to reset?
I had the same behaviour with the Enabled property always being displayed as e.g. chkReportFinance.enabled = False.
This was easily fixed by adding a line Dim Enabled, which capitalised all instances, then removing the line.
Tim Williams said:
"Sometime if you have (eg) defined a variable with the name application then the compiler gets "stuck" on that case and doesn't correct later uses to Application, even after renaming the variable. If the problem persists try exporting and re-importing your code modules (see Rob Bovey's "code cleaner" tool for an easy way to do this: appspro.com/Utilities/CodeCleaner.htm)"
This solved the problem. Question answered!
I am getting confusing and seemingly inconsistent results with one ActiveX DLL trying to create an instance of another.
Everything worked until we rebuilt our entire codebase, something which had never done since taking it over a few years ago. We previously just built pieces as we needed them.
The problem is occurring in multiple places, but here is a representative example:
Dim objMid As MiddlePiece.clsMyClass
Set objMid = CreateObject("MiddlePiece.clsMyClass")
This is hitting an error (48: Error in loading DLL) on the CreateObject line. I tried changing around the code and came up with the following results.
Dim objMid As MiddlePiece.clsMyClass
Set objMid = New MiddlePiece.clsMyClass
That gives me error 48 again.
Dim objMid As Object
Set objMid = New MiddlePiece.clsMyClass
That also gives error 48.
Dim objMid As Object
Set objMid = CreateObject("MiddlePiece.clsMyClass")
That one actually works.
Can anyone explain what the real difference is between these, and why only the last one works now, whereas at least the first one was working before?
I think I understand the difference between early and late binding, and that only the last example is an instance of late binding, but I've checked and confirmed that on both the build PC and the test machine, the registry contains the same version of MiddlePiece.dll, so I'm not clear on why this would fail.
The problem seems to stem from the fact that MiddlePiece.dll was built with Microsoft ActiveX Data Objects. There have been numerous issues related to this ever since we moved from Windows XP to Windows 7. The msado26.tlb library no longer worked for us, so we had to change our references to that library to refer to msado60_Backcompat.tlb instead. That seemed to work for a while, but we've since had more trouble with two different versions of msado15.dll. The newest version is breaking code in both VB6 and C++.
We replaced all references to msado60_backcompat.tlb with references to msado26.tlb, essentially undoing a "fix" we first implemented when we transitioned to Windows 7 about two years ago. This is basically all due to problems introduced by Microsoft. A good starting place to research the issue, for those who care to know is here. This allowed us to rebuild everything on the Windows 7 machine and resolve multiple issues.
Using VB for Excel in Excel 2003, I have no problems executing code with some non-declared variables:
numberOfBooks = 0
However, if I try to execute the same code in Excel 2007, I get a "Can't find project or library" error message.
I looked at Tools > Options and I don't have checked "Require Variable declaration". In Excel 2003 I did not use Option Explicit
What am I doing wrong? Thank you very much.
I have seen this advice (check references) a number of times and it makes sense!
However, when the fault: "can't find project or library" develops, you are in run mode and I cannot get out of it?
Waht am I missing?
I'd definitely second Daniel Cook's suggestion of checking your references list; that may be it. However I've come across some situations over the last couple of months where that error will occur in an Excel 2007 even if there is nothing wrong with the references. In part it seems to relate to the security updates that were released in August 12 ( http://technet.microsoft.com/en-us/security/bulletin/ms12-aug ). It caused some breakage in the mscomctl.ocx. The problem and (one) resolution (basically, re-registering the .ocx) is discussed in this IBM link which relates to an Excel add-in for an OLAP product called TM1: http://www-01.ibm.com/support/docview.wss?uid=swg21608271. (The error messages aren't the same as the ones that you've been getting, but I DID get your error messages on another add-in that I wrote which were not missing any references, and it turned out to be the same problem.)
The other thing I'd suggest doing is a purge of your .exd files as discussed here: http://support.microsoft.com/kb/290537 I've also found that those can cause bogus library errors, particularly after a version upgrade.
As for anything else you're doing wrong, well, personally I tend to skin anyone who works for me without using Option Explicit. 8^>
One of our companie's excel-macros (which ran quite frequently without any issues so far) all of a sudden came up with exactly the same error.
We didn't touch the code for like forever. And I honestly have still no idea what actually caused this error. Mistery Microsoft maybe? Anyways.. I finally were able to fix the bug.
Even though "Require Variable declaration" was disabled and Option Exlicit was not set in my case, declaring the variable first did the trick for me:
Dim numberOfBooks As Integer: numberOfBooks = 0
I hope this saves some headaches.
I have a Microsoft Word template with some code and some references, that has been working fine for months but has just started throwing up a spurious "User-defined type not defined" error whenever I open it or try to compile it.
I know it's a spurious error because I haven't made any significant changes to the code. In fact, I've rolled the code back to the last deployed version (which I know works fine) and I still get the error. I've also commented out all the code in the template and I still get the error. I've also removed and re-added all references (same error), and removed all the references and added them back, one by one, until the resultant compile errors are resolved, at which point I'm left with the spurious "User-defined type not defined" error. (I'm going to call this a UDTND error, from now, to avoid driving you all mad.) I think the error started popping up after I rebooted my PC. It only happens with this template, but I don't see how it can be anything to do with this template.
Interestingly, the error is subtly different from a genuine UDTND error in the following ways:
No code is highlighted when the error is displayed.
The dialog is titled "Microsoft Visual Basic", and contains the error message but, unlike a real UDTND error, doesn't contain the text "Compile error:";
It happens when the template is opened, not just when it's compiled (at least, I think that's different from a normal error).
I've tried Googling it but I just get a bazillion results from novice developers asking why they get this error, with responses telling them that they either need to declare the missing type, correct the spelling of the offending variable type, or add a reference to a missing library. I've been banging my head against my screen all afternoon, and that's helped about as much as all the other things I've tried (i.e. not at all). I have a feeling that this is something to do with a messed-up reference, but afaict they're all fine, and I've removed and re-added them, which I would expect to resolve that sort of problem.
Any ideas...?
Your trouble-shooting on References is sound. Once upon a time (and I don't recall the precise error) I was at the same point, and the reference ordering was the key. When you're designating References, you'll notice a "Priority" adjustment feature. Experiment with that and you may solve this.
I have had "User-defined type not defined" problem on several occasions when compiling Microsoft Visual Basic 6 (MSVB6) code that was compiling without a problem earlier. It seems to happen after I have had a long coding session without rebooting the computer. As you can guess, I have been using Microsoft operating systems. I currently am using Windows XP. Rebooting the computer usually fixes the problem as it so often does on Microsoft operating systems.
I have read that fully qualifying declarations also can help, e.g., "Dim oBar as Foo.Bar" instead of "Dim oBar as Bar". I have not tried this approach however.
I had a very similar problem.
My problem appeared (I think) just after I made a Search and Replace that I canceled (Ctrl+Z). There was not highligting of the problem, only the ""User-defined type not defined" error message when I compiled.
I tried:
1) restarting computer
2) changing reference ordering
3) removing functions/procedures, modules one at a time.
Didn't work. My project was written in Excel VBA and here was the solution I found.
THE SOLUTION:
I opened a new Excel file and opened the Visual Basic Editor. I then copied all Forms, Modules, and Class Modules one by one into the new file. I then Copied the Control Objects (3 Commandbuttons) from the old sheet into the new one. Now the new file was identical to the old project - only the ""User-defined type not defined" had gone and problem was solved.
Yea references would be the first step in troubleshooting this problem as already stated, but failing that id start commenting out the code in any event procedures running at start up (my experience is only with Access VBA though)
I had the same problem with Excel 2013.
It started when I did a search and replace on the name of a Custom Class.
I changed the name of the Class after I did the search and replace on all references to it and the spurious error started immediately after that.
I reverted to an earlier version ad confirmed that the problem was not there and then did the same search and replace and re-name and got the exact same behaviour again.
The Custom Class that I changed the name of only had one consumer and it was also a custom class.
I exported, removed and re-loaded the sole consumer class and the problem was fixed.
Check out this link for a Microsoft bug that might be related.
TLDR:
The reference to a package/addin/whatever probably needs to be re-referenced. Check Tools -> References in the Menu.
Also it appears that if you install Microsoft Security Advisory 960715, that certain controls are killed. There are fixes which may or may not work for you. A good article is on this blog:
VSOD Blog