Calling a DLL function
I am working in Access 2002, specifically VBA.
I have a custom DLL that has functions I need to call. I did not write the DLL and only know the functions that the provider told me I can call. For example:
I have this line in a public code module
Public Declare Function OpenDrawer Lib "MSPOS_USB.dll" (ByVal DeviceHandle As Long) As Integer
I call the function like this, result = OpenDrawer(DrawerHandle).
Is there a way, in the declaration, to replace the value in the strings dynamically? Instead of "MSPOS_USB.dll" I would like to modify this value in runtime. I tried using a string variable and it will not work.
Thanks,
Brian
I have a custom DLL that has functions I need to call. I did not write the DLL and only know the functions that the provider told me I can call. For example:
I have this line in a public code module
Public Declare Function OpenDrawer Lib "MSPOS_USB.dll" (ByVal DeviceHandle As Long) As Integer
I call the function like this, result = OpenDrawer(DrawerHandle).
Is there a way, in the declaration, to replace the value in the strings dynamically? Instead of "MSPOS_USB.dll" I would like to modify this value in runtime. I tried using a string variable and it will not work.
Thanks,
Brian
Maybe you could dynamically create a module, append the code you want to the module, save the module, then delete the module when done. However, I am not sure how VBA would handle API calls. I think the dll file is loaded into memory when the application starts, and I am not sure if you would be able to load it at runtime.
I think the best you could do is create a class module as a wrapper for the DLL functions.
declare all your different dll files there and create one class with different methods, properties, etc...
I think the best you could do is create a class module as a wrapper for the DLL functions.
declare all your different dll files there and create one class with different methods, properties, etc...
![Avatar of [ fanpages ]](https://filedb.experts-exchange.com/files/public/2020/2/28/4acbe344-900b-4e79-96ce-65fe58a6f004.png){kind=small}
Hi Brian,
You can load DLL's dynamically based on filename (using the LoadLibrary API call - see link below), but I'm curious why you would wish to "Instead of "MSPOS_USB.dll" I would like to modify this value in runtime". Perhaps you could elaborate on your reason for wanting to do this, so we may advise accordingly.
[ http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp ]
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
BFN,
fp.
You can load DLL's dynamically based on filename (using the LoadLibrary API call - see link below), but I'm curious why you would wish to "Instead of "MSPOS_USB.dll" I would like to modify this value in runtime". Perhaps you could elaborate on your reason for wanting to do this, so we may advise accordingly.
[ http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp ]
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
BFN,
fp.
ASKER
I was having grief when calling the function.
Public Declare Function OpenDrawer Lib "MSPOS_USB.dll" (ByVal DeviceHandle As Long) As Integer - On some computers it would work fine, on some it would not. When I put the actual path to the DLL in the call, it always works. - Public Declare Function OpenDrawer Lib "C:\Progra~1\InstallFolder
The only problem is that path may change, depending on where my application winds up getting installed. The DLL will always reside in the install folder of my application. A USB cash drawer is what is getting controlled by this DLL. When I install the cash drawer on a machine, I have to use their software to set it up. I'm sure that this is part of the problem, although I don't know any other way of getting around it then having a copy of the DLL in my install folder and then pointing to it.
I don't understand much of what is going on behind the scenes here, so there may be an entirely different solution, I can't say.
Public Declare Function OpenDrawer Lib "MSPOS_USB.dll" (ByVal DeviceHandle As Long) As Integer - On some computers it would work fine, on some it would not. When I put the actual path to the DLL in the call, it always works. - Public Declare Function OpenDrawer Lib "C:\Progra~1\InstallFolder
The only problem is that path may change, depending on where my application winds up getting installed. The DLL will always reside in the install folder of my application. A USB cash drawer is what is getting controlled by this DLL. When I install the cash drawer on a machine, I have to use their software to set it up. I'm sure that this is part of the problem, although I don't know any other way of getting around it then having a copy of the DLL in my install folder and then pointing to it.
I don't understand much of what is going on behind the scenes here, so there may be an entirely different solution, I can't say.
Sounds like you should focus your attention on registering the dll in your setup. If you register the dll with windows you should not have to put a path when declaring the function. The most common approach is to place a copy of the dll file in the windows system32 folder. Then register the dll using regsvr32. However there are alternatives to using regsvr32. (http://www.vbusers.com/code/codeget.asp?ThreadID=46&PostID=1&NumReplies=0)
If you have access to Office Developer editions there is a package and deployment wizard which will handle your setup for you.
If you have access to Office Developer editions there is a package and deployment wizard which will handle your setup for you.
ASKER
regsvr32 will not work, something about it not being a COM or ActiveX dll. Another thing is that the cash drawer may get added on at some point after the application has already been installed, so I can't necessarily depend on the installation package.
If you use Public Declare Function OpenDrawer Lib "MSPOS_USB.dll" (ByVal DeviceHandle As Long) As Integer, then you can simply add (progrmatically) the actual folder where the DLL is located to the user's PATH environment variable.
Is this a practical approach?
BFN,
fp.
Is this a practical approach?
BFN,
fp.
ASKER
Hey,
I don't really know if it's a practical approach, I'm not quite sure how to do it, not quite sure what exactly it is I would be altering and not quite sure if it would cause any other problems with other programs.
I'm open to hearing more though :->
Brian
I don't really know if it's a practical approach, I'm not quite sure how to do it, not quite sure what exactly it is I would be altering and not quite sure if it would cause any other problems with other programs.
I'm open to hearing more though :->
Brian
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
fanpages - worked great, thanks!
No, sorry...