32 bit to 64 bit

[GraeagleBill]

I have an app developed in Access 2013 with the app's source as file type mdb. The file is formatted for 2002 - 2003, as I still need to do maintenance on right-click options created prior to 2007 ribbons. My Access 2013 is the 32 bit version, whereas one of my users is running Access 365 64 bit version. When the user opened the front-end mdb file, they were greeted with the message seen on the image included below. I've never personally encountered this condition and, from what I've read so far, it appears that all I need to do is add the "ptrSafe" attribute to the API declares used by the app. Is that all that I need to do?

[Micron]

Yup. In fact if I was developing anything that uses API's every call would be set up for this. A zillion pages on this topic. Here's one
https://stackoverflow.com/questions/...64-bit-windows

[GraeagleBill]

My head just exploded! I only have two sets of declare functions in my app, Terry Kreft's Clipboard code and ShellWait. From what I read, or tried to read, the ptrSafe will give compiler errors if I attempt to compile my A2013 code. I added the ptrSave attribute to just one of the declare statements and compiled without compilation errors, so I'll update the mdb file and try running on one of my user's machines when I have the opportunity on Sunday. My Windows 10 has been on 64 Bit for ages, so I'm still not clear what is triggering the issue?

[Micron]

Don't go by one thread; read a few at least. AFAIK, if properly written the lines beginning with # will compile regardless of the bit version. I have included them in code before and compiled them in 32 bit. I would 'never' purposefully install 64 bit office for myself.

[GraeagleBill]

I would 'never' purposefully install 64 bit office for myself.

Yes, I can remember years ago about the evils of 64 bit versions of Office so, like you, I don't install the 64 bit versions. I'll install my app as is with the addition of the ptrSave where needed on Sunday and see what happens.

[GraeagleBill]

All my A2013 (Program Files(x86)) "Declare Function" statements updated to "Declare ptrSafe Function" and compiled without any errors, the app functioned normally. I'll load the app on a 64 bit (Program Files) A365 on Sunday and post the results.

[isladogs]

Adding PtrSafe will allow it to compile but won't necessarily be enough to make it work correctly.
For example, if your APIs contain handles/pointers such as hWnd As Long...those will need to be changed to LongPtr.
E.g. hObject should probably be LongPtr
Similarly check all your Type declarations for handles/pointers

[GraeagleBill]

Thanks Colin, I'll have an opportunity to check that out before the day is out.
Bill

[GraeagleBill]

Still trying to gain enough hands-on time of the 64bit Access machine so I can put this caper "to bed". So far, the 64bit system simply complains when the app is launched but continues okay after the initial error message. PtrSafe is absolutely required with the API declares but changing the "As Long" to "As LongPtr" sends the app off the cliff, I'll try to be more specific about that as symptoms are revealed. I've become suspicious that there's a dual installation of OFFICE 365 on the troublesome machines and I'll check that out at next opportunity.

[Micron]

Why not make use of the 64 bit user's time?