I'm facing a problem importing a DLL on different environments.
I have to check Windows platform and import the third-party DLL that will be placed in C:\Program Files\ (for 32-bit) or C:Program Files (x86)\ (for 64-bit).
Before the code was written like this:
Declare Function RDRCConnect Lib "c:\program files\TP-DLL\RDRCAP32.DLL" (ByVal lpszServerName As String, ByVal lNetConnType As Integer, ByVal lpszParam1 As String, ByVal lpszParam2 As String, ByVal lpszParam3 As String, ByRef lNetConn As Integer, ByRef lNetErr As Integer) As Integer
Declare Function RDRCDisconnect Lib "c:\program files\TP-DLL\RDRCAP32.DLL" (ByVal lNetConn As Integer, ByRef lNetErr As Integer) As Integer
...and I changed to use attributes:
Private Const CheminDLL As String = "C:\Program Files\TP-DLL\RDRCAP32.DLL"
<System.Runtime.InteropServices.DllImport(CheminDLL)>
Private Shared Function RDRCConnect(ByVal lpszServerName As String, ByVal lNetConnType As Integer, ByVal lpszParam1 As String, ByVal lpszParam2 As String, ByVal lpszParam3 As String, ByRef lNetConn As Integer, ByRef lNetErr As Integer) As Integer
End Function
How can I change the DLL path dinamically in this scenario, once the DLLImport expects a Constant as parameter?
There's no way to pass anything other than a constant into the attribute, since attributes, by definition are evaluated at compile-time, not at runtime. There may be better alternatives, but one option I can give you would be to create separate imports for each version:
<DllImport("C:\Program Files\TP-DLL\RDRCAP32.DLL", EntryPoint := "RDRCConnect")>
Private Shared Function RDRCConnect32(ByVal lpszServerName As String, ByVal lNetConnType As Integer, ByVal lpszParam1 As String, ByVal lpszParam2 As String, ByVal lpszParam3 As String, ByRef lNetConn As Integer, ByRef lNetErr As Integer) As Integer
End Function
<DllImport("C:\Program Files (x86)\TP-DLL\RDRCAP32.DLL", EntryPoint := "RDRCConnect")>
Private Shared Function RDRCConnect64(ByVal lpszServerName As String, ByVal lNetConnType As Integer, ByVal lpszParam1 As String, ByVal lpszParam2 As String, ByVal lpszParam3 As String, ByRef lNetConn As Integer, ByRef lNetErr As Integer) As Integer
End Function
Then you would need to choose which one to call appropriately each time you call the method.
I just stumbled upon this a couple of days ago when I had a similar issue to yours and it put me on the right path. Look for it here.
If the dlls are the same (same name and signatures) but just in different locations then you can p/invoke LoadLibrary explicitly with the full path of the dll as determined at runtime. As long as you do this before you invoke any of the exported APIs then it will use the one already loaded as long as the name of the dll in the import is the same.
Related
This question already has answers here:
PInvokeStackImbalance exception when using IntPtr in .NET 4? (Works in .NET 3.5)
(3 answers)
Closed 4 years ago.
I have a problem with my code, which it can be run on vb6 but somehow it crashed on vb.net
Public Declare Function GetPrivateProfileString Lib "kernel32" Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As String, ByVal lpDefault As String, ByVal lpReturnedString As String, ByVal nSize As Long, ByVal lpFileName As String) As Long
And here is how i call that function:
Dim lRetval As Long
'Get Host IP Address in host.ini
sHostIP = Space(128)
lRetval = GetPrivateProfileString("HOSTPATH", "HOSTIP", "", sHostIP, Len(sHostIP), "Host.ini")
The error says:
Managed Debugging Assistant 'PInvokeStackImbalance' : 'A call to PInvoke function 'BDS ByPass!CreateBulkCIF.GlobalClass::GetPrivateProfileString' has unbalanced the stack. This is likely because the managed PInvoke signature does not match the unmanaged target signature. Check that the calling convention and parameters of the PInvoke signature match the target unmanaged signature.'
Please help... I cant find any something useful anywhere.
The most common cause of this issue is using a function signature that was intended for VB6 rather than VB.NET. If you have a parameter or return of type Long then that is almost certainly the case. Windows API functions and other unmanaged APIs generally work with 32-bit integers. In VB6, the Long type was 32-bit and the Integer type was 16-bit. In VB.NET, the Long type is 64-bit and the Integer type is 32-bit. You should almost always be using Integer rather than Long in VB.NET.
Pinvoke.net shows the signature for that function as the following:
<DllImport("kernel32.dll", SetLastError:=True)>
Private Shared Function GetPrivateProfileString(ByVal lpAppName As String,
ByVal lpKeyName As String,
ByVal lpDefault As String,
ByVal lpReturnedString As StringBuilder,
ByVal nSize As Integer,
ByVal lpFileName As String) As Integer
End Function
You should use that site as your first choice for VB.NET API signatures.
I have a service that runs and saves a file to a remote server. This works within the service but now I need to send a command
Public Declare Function cwbDQ_Create Lib "Cwbdq" (ByVal qName As String, ByVal lName As String, ByVal sName As String, ByVal queueAttr As Integer, ByVal errorHandle As Integer) As Integer
Public Declare Function cwbDQ_SetConvert Lib "Cwbdq" (ByVal dataHandle As Integer, ByVal convert As Integer) As Integer
rc = cwbDQ_Create(queueName, libName, sysName, attrHandle, errHandle)
rc1 = cwbDQ_SetConvert(dataHandle, convert)
This is where is stops processing, the service keeps running it just doesnt do anything with this.
I'm trying to call the following unmanaged dll and it returns an error:
Attempted to read or write protected memory
' this is the declare part
Declare Ansi Function GuestCard Lib "C:\proRFL.Dll" (ByVal fUSB As Byte,
ByVal dlsCoID As Long, ByVal CardNo As Integer, ByVal dai As Integer,
ByVal llock As Integer, ByVal pdoors As Integer, ByVal BTime As String,
ByVal ETime As String, ByVal LockNo As String, ByVal Buffer As String) As Integer
' this is the calling part
Dim st As Integer = GuestCard(flagUSB, CLng(dlsCoID), CInt(CardNo) Mod 16, CInt(dai) Mod 256, llock, pdoors, BTime, ETime, LockNo, bufHexStr)
What have I done wrong?
Found the problem. I should declare the function in a module instead of a class. A simple yet stupid mistake. Thank you all for helping me out. #GSerg You are right about the type. Tank you.
I am trying to call TrackPopupMenu function to display a menu at runtime from managed VB.NET code.
Below is the error I am getting :
PInvokeStackImbalance was detected Message: A call to PInvoke function
'UeWIPopupX!UeWIPopupX.mDeclares::TrackPopupMenu' has unbalanced
the stack. This is likely because the managed PInvoke signature does
not match the unmanaged target signature. Check that the calling
convention and parameters of the PInvoke signature match the target
unmanaged signature.
Below is the declaration I am using for TrackPopupMenu function :
<DllImport("user32.dll", CharSet:=CharSet.Auto, SetLastError:=True, CallingConvention:=CallingConvention.StdCall)> _
Friend Function TrackPopupMenu(ByVal hMenu As Long, ByVal wFlags As Integer, ByVal x As Integer, ByVal y As Integer, ByVal nReserved As Integer, ByVal hWnd As IntPtr, ByVal lprc As RECT) As Integer
End Function
Below is the code for calling TrackPopupMenu function :
dim lpRc as RECT
Dim tP As POINTAPI
Dim lR as Integer
Dim lUn as Integer
lUn = TPM_RIGHTBUTTON Or TPM_TOPALIGN Or TPM_LEFTALIGN Or TPM_RETURNCMD
tP.x = 50
tP.y = 100
'Here I am getting the error
lR = TrackPopupMenu(m_ppMenu.Tools(1).hMenu, lUn, tP.x, tP.y, 0, m_hWndOwner, lpRC)
Below is the declaration for rectangle RECT:
<StructLayout(LayoutKind.Sequential, CharSet:=CharSet.Auto)> _
Structure RECT
Dim Left As Integer
Dim Top As Integer
Dim Right As Integer
Dim Bottom As Integer
End Structure
All the arguments during call of TrackPopupMenu has some values.
I tried different callingConvention but still getting the error.
I am not able to solve this. Does anyone know how to resolve this issue ?
Your declaration is wrong. The first argument is a handle to the menu, it must therefore be IntPtr. The last argument is a pointer to RECT. ByRef in VB.NET. Since it isn't actually used, you are better off declaring it ByVal IntPtr so you don't need the RECT declaration. Pass IntPtr.Zero in your call. The return value is Boolean, not Integer. Throw a Win32Exception if you get a False return. Fix:
<DllImport("user32.dll", CharSet:=CharSet.Auto, SetLastError:=True)> _
Friend Function TrackPopupMenu(ByVal hMenu As IntPtr, ByVal wFlags As Integer, _
ByVal x As Integer, ByVal y As Integer, ByVal nReserved As Integer, _
ByVal hWnd As IntPtr, ByVal ignored As IntPtr) As Boolean
End Function
There are some hints that you didn't get the menu right, hard to imagine how you came up with Long as the argument type. Do note that this function is already ably wrapped in .NET, having to pinvoke it should be extremely rare. TrackPopupMenu is already called by the .NET ContextMenu class. The ContextMenuStrip class gives a more modern version of it with better rendering options.
I have code that needs to run on both Excel 2003 and Excel 2007, and there are a few spots where changes in the versions cause the code to halt. I tried separating these lines out with If-Else statements, but the code won't compile on either because it doesn't recognize the code used for the other. Is there any way I could tell one version to ignore a block of code, similar to a C or C++-style #ifdef, in VBA?
This is a good starting point, but it won't work with the version of Excel that its running on, since that can only be figured out at run-time, not compile time.
If you need to branch your code based on information only discoverable at run time you might consider late binding as a solution. There are two ways you can sneak around version problems.
The first way can be used if you need to Access a property or method that only exists in certain versions, you can use CallByName. The advantage of call by name is that it allows you to preserve early binding (and intellisense) for your objects as much as possible.
To give an example, Excel 2007 has a new TintAndShade property. If you wanted to change the color of a range, and for Excel 2007 also ensure TintAndShade was set to 0 you would run into trouble because your code won't compile in Excel 2003 which does not have TintAndShade as a property of the range object. If you access the property that you know is not in all versions using CallByName, you code will compile in all versions fine, but only run in the versions you specify. See below:
Sub Test()
ColorRange Selection, Excel.Application.version, 6
End Sub
Sub ColorRange(rng As Excel.Range, version As Double, ParamArray args() As Variant)
With rng.Interior
.colorIndex = 6
.Pattern = xlSolid
If version >= 12# Then
'Because the property name is stored in a string this will still compile.
'And it will only get called if the correct version is in use.
CallByName rng.Interior, "TintAndShade", VbLet, 0
End If
End With
End Sub
The second way is for classes that have to be instantiated via "New" and don't even exist in old versions. You won't run into this problem with Excel, but I will give a quickie demo so you can see what I mean:
Imagine that you wanted to do File IO, and for some bizarre reason not all of the computers had the Microsoft Scripting Runtime on them. But for some equally bizarre reason you wanted to make sure it was used whenever it was available. If set a reference to it and use early binding in your code, the code won't compile on systems that don't have the file. So you use late binding instead:
Public Sub test()
Dim strMyString As String
Dim strMyPath As String
strMyPath = "C:\Test\Junk.txt"
strMyString = "Foo"
If LenB(Dir("C:\Windows\System32\scrrun.dll")) Then
WriteString strMyPath, strMyString
Else
WriteStringNative strMyPath, strMyString
End If
End Sub
Public Sub WriteString(ByVal path As String, ByVal value As String)
Dim fso As Object '<-Use generic object
'This is late binding:
Set fso = CreateObject("Scripting.FileSystemObject")
fso.CreateTextFile(path, True, False).Write value
End Sub
Public Sub WriteStringNative(ByVal path As String, ByVal value As String)
Dim lngFileNum As Long
lngFileNum = FreeFile
If LenB(Dir(path)) Then Kill path
Open path For Binary Access Write Lock Read Write As #lngFileNum
Put #lngFileNum, , value
Close #lngFileNum
End Sub
There is a comprehensive list of all Adds and Changes to Excel Object Model since 2003:
http://msdn.microsoft.com/en-us/library/bb149069.aspx
For changes between 1997 and 2000 go here:
http://msdn.microsoft.com/en-us/library/aa140068(office.10).aspx
Yes it is possible to do conditional compilation in Excel VBA. Below is a brief resource and some example code:
Conditional Compilation
#If Win32 Then
' Profile String functions:
Private Declare Function WritePrivateProfileString Lib "KERNEL32" Alias "WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As Long
Private Declare Function GetPrivateProfileString Lib "KERNEL32" Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As Any, ByVal lpKeyName As Any, ByVal lpDefault As Any, ByVal lpReturnedString As String, ByVal nSize As Long, ByVal lpFileName As String) As Long
#Else
' Profile String functions:
Private Declare Function WritePrivateProfileString Lib "Kernel" (ByVal lpApplicationName As String, ByVal lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As Integer
Private Declare Function GetPrivateProfileString Lib "Kernel" (ByVal lpApplicationName As String, ByVal lpKeyName As Any, ByVal lpDefault As Any, ByVal lpReturnedString As String, ByVal nSize As Integer, ByVal lpFileName As String) As Integer
#End If
Can you post the offending lines of code?
If it is a constant like vbYes or xlFileFormat or whatever, use the corresponding numeric value.
Show me what you got, I'll see if I can refactor it.
Bill