I've got some (32 bit) Office VBA I'd like to port to Libre Office or similar:
Type wsaData
wVersion As Integer
wHighVersion As Integer
szDescription As String * WSA_DescriptionSize
szSystemStatus As String * WSA_SysStatusSize
iMaxSockets As Integer
iMaxUdpDg As Integer
lpVendorInfo As String * 200
End Type
Public Declare Function WSAStartup Lib "ws2_32.dll" (wVersionRequested As Integer, lpWSAData As wsaData) As Long
However, the packing and type declarations for Libre Office Basic are different than MS Office VBA, and the Libre/Open office version crashes irretrievably. (Unlike MS Office for Windows, LO doesn't provide stack protection to DLL/dylib calls)
So far I haven't found any documentation for 'Declare Function', (which must be somewhere), but I also specifically need guidelines for passing strings and structs to declared dlls (which FAIK may not even be possible)
If anyone's done that specific struct before I'll be pleased :), but I also need guidelines.
Related
I am developing an app in VB.NET (for a customer with hardware using FTDI USB serial chip. Communication uses FTD2XX library and the respective Nuget package (FTD2XX.Net v1.2.1). After some update of Visual Studio (probably update to 17.1, but I am not sure) all functions except a few stopped working. Current VS version is 17.1.1.
For instance, it is possible to obtain number of devices attached by the FTDI driver:
Friend Declare Function FT_CreateDeviceInfoList Lib "FTD2XX.DLL" (ByRef lngNumDevs As Integer) As Integer
...
Dim ftStatus As Integer
Dim numDevices As Integer
ftStatus = FT_CreateDeviceInfoList(numDevices)
In the above snippet ftStatus result = 0 (i.e. OK) and numDevices is set to 1 (correct).
Problem starts when I want to do something serious:
Friend Declare Function FT_GetComPortNumber Lib "FTD2XX.DLL" (ByVal lnghandle As Integer, ByRef lplComPortNumber As Integer) As Integer
Friend Declare Function FT_Open Lib "FTD2XX.DLL" (ByVal iDevice As Integer, ByRef lnghandle As Integer) As Integer
Friend Declare Function FT_Close Lib "FTD2XX.DLL" (ByVal lnghandle As Integer) As Integer
Dim portHandle as Integer
Dim cpNumber as Long
For i% = 0 To 255
ftStatus = FT_Open(i, portHandle)
If ftStatus = FT_OK Then
ftStatus = FT_GetComPortNumber(portHandle, cpNumber)
ftStatus = FT_Close(portHandle)
' here is some non-essential code registering that port at index i% exists...
End If
Next
In the above code, FT_Open returns ftStatus = 0 (FT_OK) and sets a value for portHandle.
However, the next call, FT_GetComPortNumber, returns ftStatus = 1 (FT_INVALID_HANDLE) and the value passed to cpNumber is 0xFFFF (shows as positive, but in fact should be -1, I guess...). What is worse, FT_Close() also returns FT_INVALID_HANDLE and the port remains open. I verified it by trying to open the port from another app - access denied.
Sometimes it seems that FT_Write and FT_Read functions work despite this mess, but in my last try I could not any communication with the hardware at all.
I tried to use System.IO.Ports.SerialPort as possible workaround but that does not work at all. On top of that, I need to use bit-bang on RTS, because it controls supply voltage and reset of the hardware connected to the other side of the FTDI chip. Without possibility to bring RTS down for hundreds of milliseconds and then hold it up all the time I cannot control the hardware. AFAIK System.IO.Ports.SerialPort provides no possibility to do that.
What could be the solution?
After much trial and error, it appears to be a problem in compile configuration.
Open Solution properties Window and click on the Compile tab.
Then click on "Advanced Compile Options"
If the "Remove integer overflow checks" checkbox is not checked, check it!
I have no idea how an integer overflow check can garble a 32-bit number not involved in any arithmetic operation whatsoever, but this is what really happened. I consider this a bug in Visual Basic compiler used in Visual Studio 17.1.6 (and a number of previous versions), but I did not dig deeper in this topic.
#HansPassant writes:
The declarations are wrong, it must be lnghandle As IntPtr. The difference between Integer and IntPtr matter when you run the app in 64-bit mode. Prone to happen when targeting .NETCore, as likely in VS2022.
-- Hans Passant
I'm using an API function which returns a DWORD
Because I want intellisense on the LoWord and HiWord, rather than using a Long:
Declare Sub myAPI(ByRef outVariable As Long)
...as suggested in this list of WinAPI -> VBA datatype conversions, I'm using a type:
Public Type DWORD 'same size as Long, but intellisense on members is nice
'#Ignore IntegerDataType
LoWord As Integer
'#Ignore IntegerDataType
HiWord As Integer
End Type
Declare Sub myAPI(ByRef outVariable As DWORD)
However RubberDuck's IntegerDataType inspection reminded me that on 32 bit systems VBA converts 2-byte Integers to 4-byte Longs internally, so I'm wondering whether my DWORD declaration is really 4 consecutive bytes as expected, or 8.
I'm not familiar enough with pointers and bits & bytes to picture in my head what's going on, but I imagine the API somehow knows to fill only the lower half of each part, as I've been getting the results I expect (I think) from the API.
Your user defined type is 4 bytes is size, because Integer is 2 bytes in size.
You can check this for yourself:
Dim dw as DWORD
Dim size as Integer
size = LenB(dw)
I try to dim an unsigned integer using the line:
dim curStart as UInteger
and on running, I receive the error:
Compile Error
"User-defined type not defined"
Is there a reference library that is required in VBA to allow unsigned integers?
I'm using Visual Basic for Applications 7.1.1068
You’re out of luck - VBA does not support unsigned types.
Use a Long instead, which is a superset of a 16 bit unsigned type.
I have quite a complex Excel VBA project that runs well on 32-bit systems, I am now trying to make it work for 64-bit systems too. I have resolved all the function declarations, but still get some issues with the Long data type.
Doing some research, I come up with this (from the MSDN pages):
The actual data type that LongPtr resolves to depends on the version of Office that it is running in: LongPtr resolves to Long in 32-bit versions of Office, and LongPtr resolves to LongLong in 64-bit versions of Office.
But does that mean that I can change ALL my Dim statements from
Dim x as Long
to
Dim x as LongPtr
Should I do that everywhere? Or have I got the wrong end of the stick? Are there circumstances where that won't work or this change should be avoided?
I agree with #Ken White's answer.
Remark (for some answers):
You don't ask to convert your 32-bit project into a 64-bit project (which will not work on 32-bit).
You always NEED to declare the variable type (if you are a good programmer)
You can still use the Long data type in Office 64-bit. It will be compatible for running in 32-bit and 64-bit Office.
But sometimes, you don't have the choice, because some object's properties are not the same data type in 32-bit vs. 64-bit.
For instance, if you use ADO:
Dim rstTest As ADODB.Recordset
rstTest.RecordCount is Long on 32-bit Office
rstTest.RecordCount is LongLong on 64-bit Office
If you want to store rstTest.RecordCount into a lngCount variable, you MUST declare this variable with LongPtr otherwise it won't work on 32-bit AND 64-bit:
Dim lngCount As LongPtr
lngCount = rstTest.RecordCount
Try LongLong. From the spec, it looks like LongLong is the replacement for the 32 bit type Long.
I'm currently working on an application for my personal use. The idea is that you can open it up and reach all kind of stats of your computer (Recycle bin, Drives, Network and much more). Now I was working with the SHQueryRecycleBin from Win API.
Though I have some problems. And I've tried to look over outdated solutions for VB6 or VB.NET solutions that simply didn't work. I used the code reference from this source and to retrieve the size and count of files I used this source.
I put it in an timer, and after those 100 ticks (as I set it) were ran, I got this error:
File I/O of a structure with field 'cbSize' of type 'UInt32' is not valid.
The type of cbSize is UInteger which (apparently) automatic changes to an UInt32 - I think it's based on the system.
You should note that I'm on an Windows 7 x86 (64-bit). If have an solution for this or another piece of code that is easier than use Win API, let me know.
I have looked at the System.Management but wanted an bullet proof code that could interact with most systems.
I don't have vb.net handy to test, but the following code works perfectly well in vb6:
In a module:
Public Type SHRECYCLEBININFO
cbSize As Long
i64Size As Currency
i64NumItems As Currency
End Type
Public Declare Function SHQueryRecycleBin Lib "shell32.dll" Alias "SHQueryRecycleBinA" (ByVal pszRootPath As String, pSHQueryRBInfo As SHRECYCLEBININFO) As Long
And in a form:
Private Sub Command1_Click()
Dim info As SHRECYCLEBININFO
Dim res As Long
info.cbSize = Len(info)
res = SHQueryRecycleBin("C:\", info)
MsgBox "size: " & (info.i64Size * 10000) & " bytes" & vbCrLf & "items: " & (info.i64NumItems * 10000)
End Sub
Note the use of type "currency" - this is because vb6 doesn't have a normal data type for 64-bit integers. Type Currency is using 8 bytes, but keeps 4 decimal places, hence the multiplication by 10000 to get the results.