VBA Excel Cannot find DLL - vba

I am currently trying to add control to a Power Analyzer in an excel tool. The company provides USB drivers and the appropriate modules and DLLs. I added the DLLs to the System32 folder to ensure they were read in the path. After importing the modules and trying to run the program, I get the error "File Not Found". I then tried to hard code the location of the DLL and I received the same error.
I've looked around the internet and the only issue I could find was possibly a dependency missing from the DLL. An example of the line I'm trying to use is:
Declare Function TmSend Lib "tmctl.dll" (ByVal id As Long, ByVal msg As String) As Long
This line is apart of the module provided by the manufacturer. Is there something I'm missing to get this to work? I want to make sure before I contact the manufacturer.
EDIT:
It appears that the manufacturer uploaded a corrupt DLL causing the issue to arise. When checking the file with Dependency Walker, it failed to even read the DLL.

I see from your question that you've tried all the normal things (making sure the dll is on your path &c.)
You now need to examine the dll carefully. Download this: http://www.dependencywalker.com/
Then use it to open your dll. All the missing dependent dlls will be clearly displayed. Put those on your path too and you're done.
(To clear up some confusion: you will not need to register this dll or add a reference to it.)

Related

How can I debug a referenced DLL file from Visual Studio 2013?

To start, I know this question has been asked a million times all over the place, but as I have no experience with VB/Visual Studio, I can't find a solution that I can make sense of.
I am creating a new VB.net project(solution?), and am making calls to functions from a C library that are in a dll file. The dll file does have a pdb file and they are both stored at the same location.
In the code below it shows how I declare the functions in my VB.net code, but I have not figured out how to attach the pdb file to the project.
Declare Function InitRelay Lib "Z:\Devel\RelayAPI\Debug\RelayAPI.dll" (ByVal setbaud As Action(Of Short), ByVal getit As Func(Of Short, Short), ByVal putit As Action(Of Short), ByVal flushit As Action, ByVal delay As Action(Of Short)) As Byte
Declare Sub FreeRelay Lib "Z:\Devel\RelayAPI\Debug\RelayAPI.dll" ()
...
I am getting an exception somewhere in the DLL file, but the way I have it set up, I can not debug the dll file. Whether its adding breakpoints, or print statements, I need a way to see where in the dll the project fails.
Questions I have looked at:
How to debug a referenced dll - I tried following the menu path given in the accepted answer, but when I go to Project >> Project Properties I see no Build option. It also says I can load symbols directly in the IDE if I don't want to copy any files, but I cannot find an explanation on how to do it. EDIT - As Plutonix says below, C# Build is the equivalent of VB's Compile tab. I checked and my Debug Info is set to Full, so this does not solve my problem.
Debugging a third-party DLL in Visual Studio? - This talks about a DLL in a .NET language but mine is in C. It also only tells you how to view the code, which I already can do. I have access to the .c and .h files that are used to create the dll, I just cannot debug them at runtime.
When you debug a DLL, you can start debugging from:
The project used to create the executable that calls the DLL.
- or -
The project used to create the DLL itself.
There are a couple of ways to debug a reference DLL file using VS 2013, so here the method Microsoft uses
-->To specify an executable for the debug session
In Solution Explorer, select the project that creates the DLL.
From the View menu, choose Property Pages.
In the Property Pages dialog box, open the Configuration Properties folder and select the Debugging category.
In the Command box, specify the path name for the container. For example, C:\Program Files\MyApplication\MYAPP.EXE.
In the Command Arguments box, specify any necessary arguments for the executable.
Here I included 2 different methods for debugging a DLL file directly from Microsoft.
1> http://msdn.microsoft.com/en-us/library/605a12zt.aspx (Native Mode)
2> http://msdn.microsoft.com/en-us/library/kbaht4dh.aspx (Mixed Mode)
If this was anyhelp to you or solved your problem please make sure to drop a "vote up"
Ref. All information is from personal experience and Microsoft

VB6 reference confusion

I am a .NET Developer. I have a good understanding of how references work in .NET i.e. if you want to use AssemblyA.ClassA.MethodA in AssemblyB.classB.MethodB then you add a reference in Assembly A to Assembly B.
I am looking at a VB6 app and I get an error when I open it i.e. Errors during load. Refer to frmMain.log. I open frmMain.log and it says: "2142: Class MSComDlg.CommonDialog of control CommonDialog1 was not a loaded control class.". I have used WinMerge to compare the source code in the faulty project to a previous version of the project (which does not have the problem). The only difference is that the faulty project contains the following line in the client.vdp file:
Reference=*\G{08DBEFD7-6A19-4DCE-A533-5BDBB93683C8}#1.2#0#..\..\..\..\..\Windows\SysWOW64\Comdlg32.oca#Microsoft Common Dialog Control 6.0 (SP3)
Removing this line seems to resolve the problem. Why does this resolve the problem?
I have used Winmerge to compare yesterdays revision of the project (which does not have the problem) to todays revision of the project (which does have the problem). The only difference is the reference in the original post in the VBP file.
I would assume that someone installed the development version of this control on a different machine and then set a reference to it. When you try to open the project on your machine the reference fails. Or the control was uninstalled. It seems that the project was not using the reference and that it can be safely removed as it will still compile without the reference.
However, I have seen vb6 actually remove non-licensed controls from the form in question in this situation. So it may be that you can now compile because the form is missing a component that was there previously. Have you checked that frmMain has not changed, both the .frm and .frx files?

Why is the project unable to find a file that is right beneath its nose?

I'm trying to build a solution that has three VB projects; one that I'm working on, and two others that have interdependencies (although one says "unavailable").
In trying to compile, I get regarding the ancillary project, "Unable to find source file 'J:\DSDPAGE_T.xsl' for file 'DSDPAGE_T.xsl', located in '[TARGETDIR]', the file may be absent or locked."
J? I searched the solution to see if "J:" is hardcoded anywhere, and it's not, so...?!?
The "missing" files are right there n the project! Why is it looking in J? If that is hardcoded somewhere, why doesn't 2-clicking the err msg take me to the spot? When I do, a "File System " tab appears with two panes. On the left:
File System on Target Machine
Application Folder
System Folder
User's Desktop
User's Programs Menu
...and on the right pane, a listing of the files in that project (the same ones I see in Solution Explorer), many of whom are the subject of err msgs that they cannot be found...?!?
Is this a "VB thing" (I've never worked with VB before) or...?!?
Maybe I can create a J drive and put those files the compiler is wearing blinders about in there just so it will compile - it's not that project I need to work on anyway, I just need to let the solution compile, so I can update the other project.
UPDATE
Looking at one of these files that is visible in the project, but for which the project exhibits acute myopia, its "SourcePath" property does say "J:\DSDPAGE_T.xsl" but that property is readonly/grayed out.
UPDATE 2
In response to user2701753:
I know what you're talking about; I'm used to having these in C# projects; but in this case, there are no References folders. There is only:
Solution 'HDP' (2 projects)
HDP [project#1]
ReportFormats [folder]
[a bunch of .xsl files]
[a bunch of .vb files]
HDPSetup [project#2] <-- the problem child
DetectedDependencies [folder]
[various files: .dll, .xsl, .exe, .chi, .chm, .mdb, .bmp, .ico]
The "Detected Dependencies" folder (which I thought was maybe the VB version of References) is apparently empty - 2-clicking it does nothing; it doesn't expand or open up.
UPDATE 3
Here is perhaps a good clue: When I look at the project files in Windows Explorer, many of the files that display in Visual Studio are not seen there! For example, C:\Project\ccr\Handheld\Development\Development\HDP\HDP\HDPSetup only has this:
Debug [folder] <- empty
Release [folder] <- empty
HDPSetup.vdproj
HDPSetup.vdproj.vspscc
ccr.bmp
ccr.ico
According to VS, I would expect to see those files that it complains about being on the (nonexistent) J: drive.
UPDATE 4
This is related to the issue above.
To recap the gist: I am trying to port/upgrade a VB.NET (.NET2/VS 2003) solution to .NET4/VS2010.
The solution is comprised of three projects; the Setup project was wreaking more mayhem and malevolence than a marauding crash of rhinoceropuses (it was thought to be on drive J, apparently), and I don't need to do anything to that project, so I removed it from the solution.
That removal reduced my error count from 35 to 14.
However, the remaining errs seem related to the "other" project. There are now two; I'll call them HDP and HHTConvert (because those are their names, and my current employer doesn't seem to be as paranoid about divulging any info that would identify the company or project as my previous one was).
Although the Project Dependencies allows me to set one as dependent on the other, no matter which way I set it, it fails:
0) Both depending on each other - disallowed, circular jerk tailchasing considered bad juju
1) HDP depending on HHTConvert: Type 'HHTConvert.HHTConverter' is not defined.
2) HHTConvert depending on HDP: ""
3) Neither depending on the other:""
So it doesn't matter what I do, the same err msg appears. The line the err points to is:
Public hhtConvertThread As HHTConvert.HHTConverter
What do I have to do to introduce the HHTConvert project to the HDP project? It would seem them being in the same solution - especially when one "depends" on the other - would be enough. HHTConverter is apparently not very dependable.
UPDATE 5
Correction/amendment to my original statement: "I'm trying to build a solution that has three VB projects"
Actually, I successfully removed one project, so it is two projects, and one is C# (the "main" one, HDP, is VB).
Could that (the C#/VB "mismatch) cause the two projects to look askance upon each other, akin to the renowned Star-bellied Sneeches and the "plain vanilla" Sneeches? (I consider the plain ones to correspond to VB).
UPDATE 6
So I've got it compiling now (see my answers), but I'm getting a subsequent (runtime) error, namley: "Unable to load DLL 'cdbmenu1.dll': The specified module could not be found."
And sure enough, one of the VB files does references a DLL with that rather bland name several times, with lines such as:
Declare Sub GetLastMenu1Error Lib "cdbmenu1.dll" (ByVal Msg As String, ByVal Length As Int32)
So, I searched the local (work) network and found some copies of that DLL. I copied the newest version (2.5 years old) to HDP's bin folder, and tried to run the app. Now I get, "An attempt was made to load a program with an incorrect format"
Is this the part of the story known as "DLL Purgatory" or a rendition of "DLL Perdition"
(geschweige denn "Extraordinary DLL Rendition")?
Look at the 'References' in the projects in the Solution Explorer, these have a 'Full Path' if that's wrong drop the reference and readd it.
In the visual studio setup project have you added "active content" from VB project? Open your VB project file in a notepad, check the different files included in your project file, your setup project will try to include all those files as a part of your MSI. So open the project file and you should see the J drive there.
All those files can be taken out from the project and then re added.
I solved it: I had to add the .DLL from the C# project to the VB project's References. Once I did so, all errors disappeared. Why that wasn't already there, I have no clue.

Meaning of building a dll as export library

What is the meaning of building a dll as export library ? I just googled it.I found its a dynamic link library.Can anyone please explain what actually dll is ? and why do we need to add these statement in the .dll file
extern "c" _declspec(dllexport)
I studied the static and shared libraries but Im not sure why do we go for dll files.I learnt .dll is used for the run time. But can you help me and give me more information.Thank you in advance
I may have been a bit harsh in my comments. I am not an authority on dlls, but I have a bit of working knowledge of them, so I will try to give a short explanation.
The difference between static and shared libraries should be easy to find in a web search, but basically the code in a static library gets included into the final executable, so after the linking stage, the actual library file is not needed anymore to run the program; on the other hand, code in a shared library doesn't get included in the main program - the two parts remain separate, so the shared library (called dll on windows) will be needed every time the program is run.
"Building a dll as export library" is a bit of a confusing term. I had not heard of it before, and during a short search could only find it on a cygwin page, which you might have read, considering your initial tags. A dll can export some or all of its functions and data. Exporting means that they are available for other programs and dlls to use. Which names get exported can be controlled in various ways. One of those is inserting _declspec(dllexport) in the declaration of the function. Another way is by using a definition file with an exports section.
When creating a dll, an import library can be created. This is a file that can then be used when building an executable that uses the dll, during the linking stage, to let it know which names are exported from the dll, so the program knows how to resolve references to those functions; in other words: how to import them. (This is not always necessary. Many linkers allow you to directly link against the dll itself, thereby removing the need for an import library.)
I realize it can be confusing, but try to find a tutorial and some small examples to see how it works, and play with it a bit.

VB6 API Declaration Path

I have the following declaration in a Module:
Private Declare Function gzopen Lib "ZLIB.DLL" (ByVal filePath As String, ByVal mode As String) As Long
The following code line in a function fails, with a 'File Not Found: ZLIB.DLL' error:
lGZFileHandle = gzopen(sPath, "rb")
I'm aware that ZLIB doesn't need to be registered. My question is, where does ZLIB.DLL need to live in order for my code to work? I also know that this code is working on another machine. Currently I have ZLIB.DLL in the same folder as the application exe.
UPDATE
To my relief, the code does work when compiled. But does not work whilst running in the IDE (it does on a different machine). I still have ZLIB.DLL in the application folder.
This means that the application path must be being checked for loading the DLL.
To get around this I have tried:
Private Declare Function SetDllDirectory Lib "Kernel32" Alias "SetDllDirectoryA" (ByVal path As String) As Long
and then in the function:
SetDllDirectory App.path
This seems to allow the DLL to load, but I then get a 'Bad DLL calling convention' error instead. The plot thickens.
SOLVED
The answer seems to be here: http://www.zlib.net/DLL_FAQ.txt. It's a case of RTFM I suppose.
So, bizzarely whilst in the IDE, the STD_CALL convention is in force, but once compiled the C style calling convention suffices. It still doesn't explain why it works on a different machine in the IDE. Ho hum.
Thanks all for pointing me in the right direction.
VB6 strayed a bit from the search protocol suggested by Ken (this link is the quick reference).
The usual problem is that the .exe path (search location #1 on the list) is not the path of your VB program, but rather the VB6 IDE. So putting the DLL in the location of your VB program is no good -- unless you change the 'Start In' location of your VB6 shortcut to point to that location.
Alternately, you can put the DLL in one of the other locations specified in my link.
When running through the Visual Studio IDE, all relative files need to be placed in the following folder:
C:\Program Files\Microsoft Visual Studio\VB98\
This is because the exe that is running while debugging resides in that folder. This will allow you to debug without changing any paths.
ZLib has to be in the standard DLL load search path. See the MSDN LoadLibrary documentation for specifics on the way DLLs are found and the order of the search for them.
Are you sure ZLIB doesn't have to be registered?
I suggest you register it and try again.
EDIT
Try putting the DLL in your System folder. I believe your program will check there for it.