I'm trying to run an Excel macro with late binding code that looks like this:
Dim oThisObject As Object
Set oThisObject = CreateObject("ClassNameString")
It works fine on my machine but on my coworker's machine it's failing. I checked the references and he has the necessary reference checked (included). If I do early binding it works fine on both our machines. That would look like this:
Dim oThisType As ThisType
Set oThisType = New ThisType
How can I determine what to put as the "ClassNameString" on his computer to make late binding work.
I was googling around and found some example code that shows that exact class as something like this: "ClassNameString.1" but that didn't work on either of our computers.
My guess was that these names were in the registry somewhere and might possibly be different to avoid conflicts or something but I couldn't find anything to support that theory and when I searched my registry for the exact string I use I didn't find anything.
I also found this question which is similar from a few year ago but has no answers:
Late binding creating object VBA
Related
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.
My program needs an upgrade and I was looking for the Motherboard name and Maker(Developer).
And here's the problem there is WMI what is offered almost everywhere, and it lines up with
Console.Writeline, what i want to do is to get the Label to show the same thing what i get with WMI.
The solution what was offered by Thorster Dittmar, did not work, I tried that at the beginning:
Cannot refer to an instance member of a class from within a shared method or shared member initializer without an explicit instance of the class.
It's a bit hard to understand your question, but what I read from it is:
You want to display information you get via WMI in a Label, but the output so far is on the Console?
Well, use the following steps:
Create a Windows Forms application
Place Label on form
Copy code that accesses WMI to Form_Load event handler
Instead of Console.WriteLine(xyz) do label1.Text = xyz
That should be it. If that doesn't answer your question, please edit your question so it becomes clearer what you want.
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?
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