Im working with a CD722UN Customer Display for our POS application.
it comes with a USB2.0 connection and a installation package containing a driver ect..
now, for my application. how should i do when i want to access this driver?
at the moment i'm using the "CD722UN application"s .dll path but that can warry from clients OS ect..
Declare Function opencd722usb Lib "C:\Program\cd7220 USB\cd722dusb.dll" () As Boolean
Declare Function writecd722usb Lib "C:\Program\cd7220 USB\cd722dusb.dll" (ByRef dataoutput As Byte, ByVal Length As Integer) As Integer
Declare Function readcd722usb Lib "C:\Program\cd7220 USB\cd722dusb.dll" (ByRef DataInput As Byte, ByVal size As Integer) As Integer
Declare Function closecd722usb Lib "C:\Program\cd7220 USB\cd722dusb.dll" () As Boolean
my first thought was to first check if there was a device installed in the device manager and somehow use the driver from there???
or
distribute the .dll inside our application folder and use
searchpath ""installed directory"\cd722dusb.dll"
what is the best solution?
thanks in advance!
Figuring out how to access the device yourself is not typically a good idea when you have zero documentation on how to do so properly. There are too many possibilities and the code can be quite awkward in a managed language. You probably can't even get any documentation if the supplier already provides an access DLL.
The odds are pretty good that this DLL will work if you simply copy the DLL into the same folder as your EXE. Try that first, only the DLL name is required in the Declare statement. Look in the install directory for other DLLs that might need to be copied as well if you have trouble. The next option is to P/Invoke the SetDllDirectory() function if you can discover the path at runtime. The next option is to have the installer add the directory that contains the DLL to the system PATH environment variable. Hard-coding the path is your last resort.
Related
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
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.)
I was add to my program reference to dll and it's work good.
Declare Function adc11_get_driver_version Lib "C:\example.dll" () As Integer
but I want to write the specific location of the dll from file(config file) and replace the "C:\example.dll" by string
how can I do this?
thanks
Saar
I think you need to do dynamic PInvoke. One way to do this is using the LoadLibrary function to load the library before .Net tries to find it. You can find some sample code here.
If you leave out the location completely, it will load it based on the current directory of the application. If it's not there, then it looks in the PATH.
If you want to do something more complex, then you need to write the LoadLibrary and GetProcAddress calls yourself in your own proxy.
Some guidance here:
http://www.codeproject.com/KB/cs/dyninvok.aspx
I am coding in vb.net through visual studio 2008. I have successfully compiled a dll file from my code but I continue to get "Run-time error '453'" when I try to reference the dll in vba. I understand there is some sort of compiling error that occurs when using vb.net. Does anyone have any suggestions to fix/overcome this issue? I would like to avoid translating the code to another language as much as possible.
Here is a simple sample code that I have been trying to get functioning:
Example.dll:
Public Class Class1
Function Square(ByVal x As Double, ByRef y As Double)
y = x * x
Return 0
End Function
End Class
Macro in Example.xlsx:
Private Declare Function Square Lib "\Example.dll" (ByRef x As Double, ByRef y As Double)
Sub Test()
Dim x, y As Double
x = 2
y = 0
Call Square(x, y)
MsgBox (y)
End Sub
Thank you,
Katlynn
Ok, a truckload of issues here and assumptions are incorrect.
First up, when you use declare in VBA to a .dll, you cannot use relative path names.
So you have:
Private Declare Function Square Lib
"\Example.dll" (ByRef x As Double, ByRef y As Double)
You can’t use \Example.dll
You have to specify the FULL path name. Eg:
C:\mytestApp\Example.dll
So even if vb.net did produce a working .dll, you have to use a full path name – no relative path name is allowed.
You can place the .dll in the standard windows path names that are searched for .dll’s (so c:\windows\system32), and thus NOT have to use a full path name.
However, these days with security, adding or just tossing a .dll into a windows system folder tends to have a LOT of security issues and HUGE hassles. (windows makes this hard, and so does any virus software). So you have to use a full path name.
Next up:
Using declare in VBA is a means to call the windows API, or what we call windows x32 bit library code. This is not COM (ActiveX), but has to be raw windows x32 (or x64) native windows code.
So this is not a ActiveX, or “com” object, but raw code that you call. A standard vb.net (or any .net language) does NOT produce windows native code. The correct term is
Managed code = .net code. This code is NOT native windows code.
Un-managed code = raw windows code.
So you have to create un-managed code to use DECLARE in VBA.
So you have to use:
X86 assembler
C++
VB6
Or ANY development tool that can produce raw x32 (or if using access x64, then raw x64 native windows code).
In visual studio these days you "can" produce native windows code, but you have to use un-managed code, and that thus means c++. (c#, or vb.net don't produce native code or dll's).
So you can use c++, or VB6 or even a assembler to create these .dll’s.
Such .dlls do NOT require registration. And as noted you don’t create an “instance” of the object in VBA code, but call it directly.
These types of .dll’s (simple external library code calls) thus do not appear as a COM object. And if you in VBA editor go tools->references, then you not see these libraries appear. However, they can be ease to use, since you don't have to create a instance of the object I VBA code - you just call such code like your example.
Because the path name is hard coded with this approach, then it often a pain to use the DECLARE statement (since it is determined at VBA compile time, and not runtime). This would mean you have to place that .dll in the SAME location for each computer you deploy to. If you move or change the folder, then your code would fail.
To get around this issue, you can use the LOADLIBARY call in VBA. This will allow you at runtime to set (determine) the location of the .dll. So most developers will thus simple place the .dll in the SAME folder as the running application (same folder as the Access or in this case Excel file).
However, this assumes you create a standard windows .dll.
Can I create such native windows .dll’s in .net with vb.net?
It turns out you can with some external add-in’s for VS. I often use this approach to create these dll’s, since then I don’t have to build COM interface code, and it is VERY simple to use.
I then combine the above with VBA using a LOADLIBRARY call, and that works quite well. So in VS you can use a NuGet package (add in) and pick a .dll export add-in utility. There are several, but I used the RGeseke DLLimport with great success. These are free 3rd party choices here.
While the above reduces some hassles, you will have to adopt the VBA loadlibrary code to make this a practical choice (or always place the .dll in the same location). I also recommend this approach if you have some existing .dll’s, and want to interface to that code but don’t want to learn say c++. So I do use this approach to consume existing dll’s in vb.net, and thus in turn from Access. In effect this trick allows you to write interfaces to windows .dll code in a nice familiar language like vb.net.
However, if you not used LOADlibrary from VBA (and VB6) in the past, and are not up to speed, then I will suggest you choose the next option.
Creating COM (ActiveX) from vb.net
This is likely the best approach. And it is the most common approach. However, you have to trade off having to create a COM object in vb.net, and THEN register it on the target computer.
So, the only hassle is this requirement to register the .dll on the target computer.
Having to register (regasm.exe) the COM object on the target machine often requires elevated rights. And with companies so security conscious these days, then this installing requirement can be a hassle, but it still likely the best option.
Here is a working example of your code in vb.net.
Imports System.Runtime.InteropServices
<ClassInterface(ClassInterfaceType.AutoDual)>
Public Class Class1
Function Square(ByVal x As Double) As Double
Dim y As Double
y = x * x
Return y
End Function
End Class
Note the above including of interop, and the autoDuel setting in code. This is what allows .net to create a standard windows COM object interface that can be consumed by VBA, VB6, windows scripting, or just any platform that supports COM objects.
Settings you need for this to work:
FORCE the .net project to x86. (you using Excel x32).
So in VS go build->configuration manager. Click on platform in the grid, and choose new, choose x86 and click ok.
You should now have this:
Next up, ensure that the project is made com visible. This check box is USUALLY checked for you by default. All .net classes tend to be marked this way. But I seen it become un-checked when you mess with the previous step of changing the build to x86. So do a quick look at this setting.
Project->properties
Now on Application area, click on assembly information box.
You need to ensure this check box is set:
So above takes only a few seconds.
So check the above (they are usually are already set for you).
Next, we have to tell VS to register this COM object on our development computer. (this is that regasm.exe requirement).
So, in compile area, check this box:
Now, the above check box in VS is ONLY for your development computer and convenience. It simply does a regasm for you, and this is the magic that exposes the class as a COM object for use in VBA or ANY system that supports COM.
Note that the above check box is ONLY for your convenience on your development machine. It does NOT change, modify or do ANYTHING to the code or project.
Now to deploy this code to other machines, you have to provide a batch file or some other means to execute the regasm.exe command. As I pointed out, these does make deployment a greater hassle then the .dll approach, but you trade off other ease of coding here.
As this point, compile (build) the above.
Once you done so, you find now in the VBA editor, you can go tools->references and you find your project as a registered COM object for consuming in VBA.
You see this: (my project was call Testcom2.
And note that once you do set this reference, you MUST EXIT excel if you make changes or re-compile the .net project. (because EXCEL will have locked and have that .dll in use once you set this reference). So just remember if you going to re-compile the .net code, make sure you exit Excel.
And I changed you code a bit, since a function returns a value, and you always returning 0. You could use a call and use a Sub if you wanted, but you HAVE function defined in vb.net and did not define a sub.
So in VBA, we now have this:
Sub TEst55()
Dim cMySquare As New TestCom2.Class1
Dim a As Double
Dim b As Double
a = 10
b = cMySquare.Square(a)
Debug.Print b
End Sub
Note how even intel-sense works as I type, so the function show up as a method in VBA.
And even the types and parms show up while you type in VBA such as:
And hitting f5 in VBA to run the code, we get this as output:
100
Its been a while since I've done this so I'm not sure if its necessary anymore but did you try adding all of the COM attributes?
http://support.microsoft.com/Default.aspx?kbid=817248
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.