Adapting automatically Access code from 32-bit to 32/64-bit (1 Viewer)

[amorosik]

Is there an automatic system for converting Access code from 32-bit to 32/64-bit?
I'm asking this because, after manually adapting some parts, I see that it essentially involves duplicating the definitions of functions called from external libraries and adapting the code by replacing the Long with a LongPtr
Therefore, it seems like a perfectly automatable task

 

[xavier.batlle]

Sometimes, converting a database is not as easy as it seems. For example:
- You have to change len() to lenB() in some UDT.
- When there are copy memory APIs involved, the number of bytes copied must be changed...or not.
- Some APIs can be used with different parameters type.
- 32 bit OCX controls need to be replaced to ther 64 bit version (if exists)
- etc.

Peter Cole was working on a commercial database to convert them: Access32to64Updater
https://www.thememydatabase.co.uk/access32to64.html
I've not tested or used it!

 

[isladogs]

It’s not as simple as adding PtrSafe and converting Long to LongPtr. Not all Longs should be converted. You need to know the correct code for each API and Type statement.
There are various free and paid tools to help do this including Peter Cole’s converter and the VBE_Extras add-in.
For detailed info on the process and available tools see the series of articles on my website starting with https://isladogs.co.uk/32-64-bit-conversion/index.html

 

[sonic8]

- You have to change len() to lenB() in some UDT.

Well, yes and no.
There is no requirement to change Len to LenB for 64bit, if you did choose the correct function in the first place.
For UDTs Len and LenB will usually return the same size in 32bit context. So, very often people got away with incorrectly using Len while they should have used LenB. This mistake (on both platforms!) is not longer tolerated in 64bit context because the values are different for many UDTs.

- When there are copy memory APIs involved, the number of bytes copied must be changed...or not.

Not! - I can't think of any scenario where this would be required.
(Except in combination with incorrect use of Len/LenB, as elaborated above.)

 

[sonic8]

I see that it essentially involves duplicating the definitions of functions called from external libraries and adapting the code by replacing the Long with a LongPtr

As @isladogs mentioned, not all Long arguments need conversion.

But beyond that, you missed a very important point: The declared API functions do not exist isolated on their own. There must be other code in your application that is invoking those functions. - Otherwise you could just delete the declarations and would be done with the conversion. - The calling code must be adapted as well to pass the correct argument types!

 

[arnelgp]

Win32Api text file is found on this forrum:

Win32 API

attached is the 64 bit declarations of windows API. since many in the forum wanted to convert some VBA with API to correct declaration. if the API you are searching is not on the list, it's probably did not came together with Windows, meaning from a third party software you installed. template...

www.access-programmers.co.uk

 

[xavier.batlle]

Not! - I can't think of any scenario where this would be required.
(Except in combination with incorrect use of Len/LenB, as elaborated above.)

If I'm not mistaken, I've seen it when you copy memory addresses using Windows APIs. As you know, memory addresses length are different depending on the bitness.
This is the code I've used sometimes

' ***********************************
'    #If Win64 Then
        Private Const PTR_SIZE As Long = 8
    #Else
        Private Const PTR_SIZE As Long = 4
    #End If
Exemple:
apiCopyMemory ByVal VarPtrArray(bDibFrom), VarPtr(tSAFrom), ByVal PTR_SIZE

 

[sonic8]

I've seen it when you copy memory addresses using APIs.

Aaeh... Well, yes, this is correct if you hardcode the size of memory to be copied.
Don't do that!
A memory address has the size of a LongPtr (-> LenB!).
When copying other data from memory it usually has the size of an UDT (->LenB) or the correct size is reported by a related API function.
Don't hardcode this stuff! Hardcoded memory sizes may become incorrect by updates to Windows independently of a 32/64bit platform change.

 

[xavier.batlle]

I found it when I converted the Lebans PictureBox to 64 bit.

 

[sonic8]

Code:

' ***********************************
'    #If Win64 Then
        Private Const PTR_SIZE As Long = 8
    #Else
        Private Const PTR_SIZE As Long = 4
    #End If
Exemple:
apiCopyMemory ByVal VarPtrArray(bDibFrom), VarPtr(tSAFrom), ByVal PTR_SIZE

You could use this instead:
apiCopyMemory ByVal VarPtrArray(bDibFrom), VarPtr(tSAFrom), ByVal LenB(VarPtr(tSAFrom))

I found it when I converted the Lebans PictureBox to 64 bit.

Still, don't hardcode memory sizes, even if Lebans did it. ;-)

 

[NauticalGent]

LenB() - never heard of it...until today.

 

[sonic8]

LenB() - never heard of it...until today.

That's how well you pay attention? ;-)

There is a number of String functions having a ...B counterpart to operate on Bytes instead of characters. They are easy to overlook because Microsoft has not documented them individually but inside Note/Remark sections of the Not-B functions.
Len(B) is special because it can not only operate on strings but also on variables of other types.

 

[NauticalGent]

That's how well you pay attention? ;-)

Too close to Christmas to be mean, Santa is watching!

Thanks for the explanation, truth be told, I've rarely had to use Len() and in all those cases, it was for string operations. Now that I think on it, I do remember a Mike Wolfe (NoLongerSet) article using LenB() to check for empty strings but I didn't see the advantage of LenB() over Len().

 

[arnelgp]

I think the B there stands for Byte.
Len() will count the number of characters, while LenB() will count the number of bytes.
so, LenB will return 2 times the result of Len().

 

[AHeyne]

While we are on the subject of what needs to be considered when converting 32-bit code to 64-bit, it is also worth mentioning non-API-specific issues:

In an "ADODB.Recordset" object, the "RecordCount" property has the type "Long" in 32-bit and "LongLong" in 64-bit.

So if the number of records is to be stored in a variable, it should be defined as "LongPtr".