MS ACCESS 2013 32bit to 64bit

JohnPapa

Registered User.
Local time
Today, 09:12
Joined
Aug 15, 2010
Messages
1,034
I am trying to make my 32bit Access 2013 work with 64bit. The following works in 32bit:

Code:
Option Compare Database

I tried the following for 64bit compatibility

Code:
Option Compare Database


I receive a problem as seen in the attachment.
 

Attachments

  • jp6.png
    jp6.png
    57.8 KB · Views: 61
I am trying to make my 32bit Access 2013 work with 64bit. The following works in 32bit:

Code:
Option Compare Database

I tried the following for 64bit compatibility

Code:
Option Compare Database


I receive a problem as seen in the attachment.
That appears to be an API call in the screenshot, ChooseColorAPI. That has nothing to do with the Option Compare Database statement, which tells Access how to conduct string comparison. I call that out because you've included in the screenshots.


APIs are the main place where you have to be concerned about 32 bit/64 bit compatibility. There have been many good presentations on this topic, some of which are available on YouTube. Start here, for example:

(an especially deep dive in this one)
 
Not sure exactly what you are asking. Are you saying that you have an app developed under 32-bit Access and are trying to run it under 64-bit Access?

I suspect you need to do an advanced search in this forum for "prepare for 64-bit access" and browse a few of those articles.
 
I am trying to make my 32bit Access 2013 work with 64bit. The following works in 32bit:

Code:
Option Compare Database

I tried the following for 64bit compatibility

Code:
Option Compare Database


I receive a problem as seen in the attachment.
If you're lucky, you might get away with simply adding PtrSafe to all your API declarations. Otherwise, follow all the tutorials already given. Good luck!
 
I receive a problem as seen in the attachment.
Your very sparse code excerpts force us to guess what the problem is.
My guess:
You followed the often tried but mostly wrong approach of changing every Long data type in your API calls to a LongPtr. Now your return value of the ChooseColor API is a LongPtr (which is incorrect) and causes the type mismatch when being assigned to your lReturn variable, which is still a Long.

If you're lucky, you might get away with simply adding PtrSafe to all your API declarations.
This sentence causes the false impression that you just try to add PtrSafe without thinking and if it works in a quick test everything is fine. - This is problematic, as keeping memory addresses in API calls in Long data types may just work fine on a computer doing only little and only using 32bit address space of RAM. Once the workload increases and memory beyond 32bit addresses is used, everything will blow up right in your users face.
 
After doing some reading on the subject converting having both 32bit and 64bit, I arrived at the following and please correct me if I am wrong:
1- I do not have a need to be compatible with previous version of Access 2013, so I do not need to be involved with #VBA7. I will use the following with identifying the Bitness
#If Win64 then

#Else

#End If

2- I thank GPGeorge with the 3 YouTube videos. I found the second video of better use.

3- Just adding ptrSafe will not do it, in most cases

4- Looking up every variable is a nightmare

5- In the second YouTube video there is an APIViewer that you can look up the 64bit equivalent. I will try this for the time being.

Many thanks to all for your help.
 
I arrived at the following and please correct me if I am wrong:
1- I do not have a need to be compatible with previous version of Access 2013, so I do not need to be involved with #VBA7. I will use the following with identifying the Bitness
#If Win64 then
If you don't need to be compatible to older versions (A2007 and earlier!), you do not need to detect the bitness at all if you write your code to be compatible with 32bit and 64bit. The hybrid LongPtr data type makes this straight-forward. Only in very rare circumstances the the actual bitness is relevant then.
 
If you don't need to be compatible to older versions (A2007 and earlier!), you do not need to detect the bitness at all if you write your code to be compatible with 32bit and 64bit. The hybrid LongPtr data type makes this straight-forward. Only in very rare circumstances the the actual bitness is relevant then.
The software which I am trying to make 32bit and 64bit compatible is more than 25 years old, but at some point I updated it to A2013, so I do not need to be compatible with anything earlier than A2013.

Do I change all Long to LongPtr without investigation?

Edit: And add a PtrSafe after Declare?
 
Last edited:
The software which I am trying to make 32bit and 64bit compatible is more than 25 years old, but at some point I updated it to A2013, so I do not need to be compatible with anything earlier than A2013.

Do I change all Long to LongPtr without investigation?

Edit: And add a PtrSafe after Declare?
AFAIK, LongPtr is not a true Data Type. It merely transforms to Long for a 32bit and to LongLong for a 64bit. I have a feeling that this will not be enough.
 
Do not change all Long to LongPtr.
Also you probably do not need conditional compilation at all. If you do need it, #If VBA7 is a much better option than #If Win64

See my series of 5 articles starting with:
 
Do not change all Long to LongPtr.
Also you probably do not need conditional compilation at all. If you do need it, #If VBA7 is a much better option than #If Win64

See my series of 5 articles starting with:
I will look at your link, which I thank you for.

I do not need to be compatible with earlier versions of A2013, so why do you mention #if VBA7?
 
Do not change all Long to LongPtr.
Also you probably do not need conditional compilation at all. If you do need it, #If VBA7 is a much better option than #If Win64

See my series of 5 articles starting with:
Many thanks for clarifying what is needed and what is not. No conditional is needed.

I attached the utility from the second YouTube on #2 above. If you type the name of the function you can get the correct format.
 

Attachments

You should ask permission from the author Dennis Wallentin before attaching the WinAPIViewer utility here.
you don't need permission if he share the db on public forum.
there is also correct win64 declaration here:
 
Last edited:
I will look at your link, which I thank you for.

I do not need to be compatible with earlier versions of A2013, so why do you mention #if VBA7?
You only need #If VBA7 if some users have A2007 or earlier
 
you don't need permission if he share the db on public forum.
He didn't. The app was for many years available solely at Excel MVP, Ron de Bruin's website. Unfortunately Ron removed all of his Excel content a couple of years ago.
That was the reason I asked Dennis for permission to publish his excellent utility on my website

The conditional compilation template in your post is unnecessarily complex.
 
The goal is to help people on this forum. I made explicit reference to the YouTube video.

More importantly the conditional template on arnelgp's post is as simple as it can be. As I mentioned I do not need VBA7

I am close to converting my software and I get a compile error in the following module:

Code:
Option Compare Database


The problem is at

Code:
' Copy the x86 native code into the allocated memoryA

It says Compile error Type mismatch
 
Not on that line, that is commented out?
Is it not in Green?
 
The goal is to help people on this forum. I made explicit reference to the YouTube video.

More importantly the conditional template on arnelgp's post is as simple as it can be. As I mentioned I do not need VBA7

I am close to converting my software and I get a compile error in the following module:

Code:
Option Compare Database


The problem is at

Code:
' Copy the x86 native code into the allocated memoryA

It says Compile error Type mismatch
My point still stands. The APIViewer shouldn't be posted here.
@arnelgp's template is definitely not 'as simple as it can be'. Read my articles to understand why I said that
 
' Copy the x86 native code into the allocated memoryA

The goal is to help people on this forum. I made explicit reference to the YouTube video.

More importantly the conditional template on arnelgp's post is as simple as it can be. As I mentioned I do not need VBA7

I am close to converting my software and I get a compile error in the following module:

Code:
Option Compare Database


The problem is at

Code:
' Copy the x86 native cod
[QUOTE="JohnPapa, post: 1931687, member: 81674"]
The goal is to help people on this forum. I made explicit reference to the YouTube video.

More importantly the conditional template on arnelgp's post is as simple as it can be. As I mentioned I do not need VBA7

I am close to converting my software and I get a compile error in the following module:

[CODE]Option Compare Database


The problem is at

Code:
' Copy the x86 native code into the allocated memoryA

It says Compile error Type mismatch

e into the allocated memoryA[/CODE]

It says Compile error Type mismatch
[/QUOTE]
Not on that line, that is commented out?
Is it not in Green?

Not on that line, that is commented out?
Is it not in Green?

The goal is to help people on this forum. I made explicit reference to the YouTube video.

More importantly the conditional template on arnelgp's post is as simple as it can be. As I mentioned I do not need VBA7

I am close to converting my software and I get a compile error in the following module:

Code:
Option Compare Database


The problem is at

Code:
' Copy the x86 native code into the allocated memoryA

It says Compile error Type mismatch

Not on that line, that is commented out?
Is it not in Green?
Maybe there was a mixup. The actual line is the following line

Code:
           Call CopyMemoryAnsi(MouseHookAddr, NativeCode, Len(NativeCode))

It says Compile error Type mismatch and highlights "MouseHookAddr"


I repeat the entire module except the Native Code because it was too big. I just assigned NativeCode = "123"

Code:
Option Compare Database
Option Explicit

'   *****************************************************************************
'   * ------------      MOUSE HOOK for Microsoft(r) Access VBA     ------------ *
'   * ------------      (c) Wayne Phillips / iTech Masters 2009    ------------ *
'   * ------------          http://www.everythingaccess.com        ------------ *
'   *****************************************************************************
'   *                                                                           *
'   * This module exposes a function that creates an in-memory, COM-compatible  *
'   * object that is written in native x86 code rather than VBA.                *
'   *                                                                           *
'   * The purpose of this module is to allow easy disabling of the mouse scroll *
'   * wheel in Forms, without needing a DLL and without VBA problems usually    *
'   * associated with subclassing windows:                                      *
'   * http://support.microsoft.com/?kbid=278379                                 *
'   *                                                                           *
'   * - v1.2 28/08/2009 - now compatible with both VBA5 and VBA6 (Access 97+)   *
'   * - v1.4 01/09/2009 - Scroll disabled by default, for convenience           *
'   * - v1.5 04/12/2009 - now the methods Init and Scroll are case insensitive  *
'   *                                                                           *
'   * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
'   * All the benefits of using a native compiled DLL - without needing a DLL!  *
'   *                                                                           *
'   *   You are free to include this module in your project provided that you   *
'   *  leave this copyright notice in place and that no modifications are made. *
'   * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
'   * Instructions:                                                             *
'   *                                                                           *
'   *  Add the following code to your OnOpen event:                             *
'   *                                                                           *
'   *     Private Sub Form_Open(Cancel As Integer)                              *
'   *         Static MouseHook As Object                                        *
'   *         Set MouseHook = NewMouseHook(Me)                                  *
'   *     End Sub                                                               *
'   *                                                                           *
'   *****************************************************************************

Private Declare Function VirtualAlloc Lib "kernel32" (ByVal Address As Long, ByVal Size As Long, ByVal AllocationType As Long, ByVal Protect As Long) As Long
Private Declare Function GetModuleHandleA Lib "kernel32" (ByVal ProcName As String) As Long
Private Declare Function GetProcAddress Lib "kernel32" (ByVal Module As Long, ByVal ProcName As String) As Long
Private Declare Sub CopyMemoryAnsi Lib "kernel32" Alias "RtlMoveMemory" (ByVal Dest As Long, ByVal Source As String, ByVal Size As Long)
Private Declare Sub CastToObject Lib "kernel32" Alias "RtlMoveMemory" (ByRef Dest As Object, ByRef Source As Long, ByVal Size As Long)

Private Const SIZEOF_PTR32              As Long = &H4
Private Const PAGE_EXECUTE_RW           As Long = &H40
Private Const MEM_RESERVE_AND_COMMIT    As Long = &H3000
Private Const ERR_OUT_OF_MEMORY         As Long = &H7

Private Type IDispatchVTable
    QueryInterface As Long
    AddRef As Long
    Release As Long
    GetTypeInfoCount As Long
    GetTypeInfo As Long
    GetIDsOfNames As Long
    Invoke As Long
End Type

Public Function NewMouseHook(ByRef Form As Access.Form) As Object

    Dim NativeCode As String
    Dim Kernel32Handle As Long
    Dim GetProcAddressPtr As Long
    Dim MouseHookAddr As Long
    Dim MouseHookLoader As Object
    Dim LoaderVTable As IDispatchVTable
            
    NativeCode = "123"
            
    ' Allocate the executable memory for the object
        MouseHookAddr = VirtualAlloc(0, Len(NativeCode), MEM_RESERVE_AND_COMMIT, PAGE_EXECUTE_RW)

    If MouseHookAddr <> 0 Then
    
        ' Copy the x86 native code into the allocated memory
            Call CopyMemoryAnsi(MouseHookAddr, NativeCode, Len(NativeCode))
              
        ' Force the memory address into an Object variable (also triggers the shell code)
            LoaderVTable.QueryInterface = MouseHookAddr
            Call CastToObject(MouseHookLoader, VarPtr(VarPtr(LoaderVTable)), SIZEOF_PTR32)
            If Not TypeOf MouseHookLoader Is VBA.Collection Then
                Set NewMouseHook = (MouseHookLoader)
                Set MouseHookLoader = Nothing
            End If
            
        ' Initialize our COM object
            Kernel32Handle = GetModuleHandleA("kernel32")
            GetProcAddressPtr = GetProcAddress(Kernel32Handle, "GetProcAddress")
            Call NewMouseHook.Init(Kernel32Handle, GetProcAddressPtr, Form.hwnd)
            
        ' Disable the scroll wheel by default.
            NewMouseHook.Scroll = False
        
    Else
    
        Err.Raise ERR_OUT_OF_MEMORY
    
    End If
    
End Function
 
Last edited:

Users who are viewing this thread

Back
Top Bottom