Solved Making an old 32-bit MDB file 64-bit-compilable (1 Viewer)

[AOB]

Hi guys,

Hoping somebody can save me some heartache here...

I've inherited a very old database (MDB) format. It references a tonne of Windows API's (rough count of between 70-100 declarations) and obviously 64-bit Office wasn't on the horizon back then as none of them use conditional compiling or pointer-safe declarations. For example :

Private Declare Function apiCreateWindowEx Lib "user32.dll" Alias "CreateWindowExA" 
    (ByVal dwExStyle As Long, ByVal lpClassName As String, ByVal lpWindowName As String, ByVal dwStyle As Long, ByVal x As Long, ByVal y As Long, _
        ByVal nWidth As Long, ByVal nHeight As Long, ByVal hWndParent As Long, ByVal hMenu As Long, ByVal hInstance As Long, lpParam As Any) As Long

I've gone through the entire code and added conditional compiling and pointer safe declarations, so changing the above, to this :

#If VBA7 Then
    Private Declare PtrSafe Function apiCreateWindowEx Lib "user32" Alias "CreateWindowExA" _
        (ByVal dwExStyle As Long, ByVal lpClassName As String, ByVal lpWindowName As String, ByVal dwStyle As Long, ByVal x As Long, ByVal y As Long, _
            ByVal nWidth As Long, ByVal nHeight As Long, ByVal hWndParent As LongPtr, ByVal hMenu As LongPtr, ByVal hInstance As LongPtr, lpParam As Any) As LongPtr
#Else
    Private Declare Function apiCreateWindowEx Lib "user32.dll" Alias "CreateWindowExA" _
        (ByVal dwExStyle As Long, ByVal lpClassName As String, ByVal lpWindowName As String, ByVal dwStyle As Long, ByVal x As Long, ByVal y As Long, _
            ByVal nWidth As Long, ByVal nHeight As Long, ByVal hWndParent As Long, ByVal hMenu As Long, ByVal hInstance As Long, lpParam As Any) As Long
#End If

(multiplied 70-100 times for each API, across about a dozen objects / modules)

Problem is, it still won't compile, because there are a tonne of variables declared which interact with the API's and obviously they aren't using 64-bit nomenclature either. So there's type mismatches all over the place. For example :

Private m_hWndDTP As Long
m_hWndDTP = apiCreateWindowEx(etc. etc. etc.)

I've also got properties in there with the same issue :

Public Property Get BackColor() As Long
    lngRet = apiSendMessage(m_hWndDTP, MCM_GETCOLOR, MCSC_BACKGROUND, 0&)
    BackColor = lngRet
End Property

So, the only ways I can think of to get around this problem are a) declare all those Long variables as something like Variant (which, to me, seems like a really bad idea) or b) add conditional declarations for every single such variable, property, etc., like this :

#If VBA7 Then
    Private m_hWndDTP As LongPtr
#Else
    Private m_hWndDTP As Long
#End If

#If VBA7 Then
    Public Property Get BackColor() As LongPtr
      lngRet = apiSendMessage(m_hWndDTP, MCM_GETCOLOR, MCSC_BACKGROUND, 0&)
      BackColor = lngRet
    End Property
#Else
    Public Property Get BackColor() As Long
      lngRet = apiSendMessage(m_hWndDTP, MCM_GETCOLOR, MCSC_BACKGROUND, 0&)
      BackColor = lngRet
    End Property
#End If

But the code is vast and it seems there are a never-ending supply of mismatched / 32-bit-strict declarations that are going to take me forever to wade through.

Before I waste too much more time trying to solve this (and I have wasted a lot already), does anybody know an "efficient" way of getting this code to compile in both 32-bit and 64-bit Office? An "option 3" I'm not aware of or a better methodology I should follow? I don't know for certain if the entire user base are on 64-bit Office yet so I can't just dump the 32-bit stuff in case somebody out there starts complaining that it's suddenly stopped working (making it 64-bit-strict would make my life a hell of a lot easier!)

Thanks in advance!

 

[Minty]

I would actually take a step back and check that the API's are still required.

Quite a lot of them may have been superseded or are now covered by inbuilt functionality, and simply need to be written using a more up-to-date method.

 

[arnelgp]

i can help in your conversion. just upload the db.

 

[AOB]

I would actually take a step back and check that the API's are still required.

Quite a lot of them may have been superseded or are now covered by inbuilt functionality, and simply need to be written using a more up-to-date method.

This would 100% be the correct and proper thing to do in this scenario, and normally that is precisely what I would do, but a) it's not my database, b) it's not even my responsibility, really (I am just helping out), c) i have no idea why these API's are used, or where, or for what purpose and therefore d) I don't have the bandwidth to spend weeks debugging the thing just to rewrite somebody else's code!

 

[AOB]

i can help in your conversion. just upload the db.

Thanks @arnelgp that is extremely kind! However, I just checked in with the owners and they reckon the user base are entirely on 64-bit M365 now so rather than trying to make it compatible with both versions, I've simply gone through all the variables (compile > debug > redim > repeat) and switched them to their 64-bit equivalent (so it will now only work on 64-bit Office) I've warned them in advance that there's no going back! Fingers crossed it runs now (it finally compiles fine so I'm feeling optimistic...)

 

[sonic8]

I've simply gone through all the variables (compile > debug > redim > repeat) and switched them to their 64-bit equivalent (so it will now only work on 64-bit Office)

That's what I would have recommended to consider.
Just keep in mind: It is not 64bit only, but VBA7 only. So, your converted code only works with Access 2010 and newer, but it works regardless of the 32bit or 64bit edition. - I think that is a reasonable limitation.