Using APIs that return LongLong values in 32 bit Access (1 Viewer)

[xavier.batlle]

Until recently I thought that we couldn't call APIs that return a LongLong values using 32bit MSACCESS. That's not true! There is a workaround.
I came across that we can use these APIs if the return value in 32 bitness is the same size as LongLong type (8 bytes), for example; Currency or UDT with two Long values.
This database shows how to manage it using the GetTickCount64() API.

 

[The_Doc_Man]

Note that even if you have 32-bit Access, more recent versions allow you to accept LongLong integers as a data type. Ac2010 definitely DID NOT like that data type but I believe Ac2013 did. Your computer must also support that as a hardware data type in order for Access to even think about it as an integer.

 

[xavier.batlle]

Note that even if you have 32-bit Access, more recent versions allow you to accept LongLong integers as a data type. Ac2010 definitely DID NOT like that data type but I believe Ac2013 did. Your computer must also support that as a hardware data type in order for Access to even think about it as an integer.

This database has been tested with 32 bit MS ACCESS 2010 and works properly. LongLong type is not allowed in any 32 bit MS ACCESS version

 

[The_Doc_Man]

I used data type QUAD (integer) in Ac2013 but I see it is not in Ac2021. Curious.

 

[xavier.batlle]

This screenshot shows the GetTickCount64() behavior of this API after 39 days on a computer turned on (32 bit Access).
As you can see the equivalent declarations:

Private Declare PtrSafe Function GetTickCount64 Lib "kernel32" Alias "GetTickCount64" () As LongPtr
Private Declare PtrSafe Function GetTickCount64 Lib "kernel32" Alias "GetTickCount64" () As Long

return negative values after 24,86 days, but the declarations using Currency or LARGE_INTEGER as a return value still are working properly.

And this is a capture after 122 days. Calls to the the API using long declataration type have restarted from 0 two times.