

As long as you started by installing the oldest version first, everything worked pretty well. There was a time in the not-too-distant past when you could safely run multiple Office versions side-by-side. Yes, that would be very nice if it worked, wouldn't it? What If I Install a 32-bit Access Runtime Alongside 64-bit Office? What's more, if you insist that your users install the 32-bit version of Office, you will need to explain the explicit extra steps they will need to take to run the non-default Office install. Up until Office 2016, you could tell your clients that your Access application only works with 32-bit Office and, oh by the way, that's the version of Office that Microsoft officially recommends you install.īeginning with Office 2019, that argument no longer holds water. If your approach to the arrival of 64-bit VBA has been to keep your head in the sand and pretend it does not exist, I have some bad news for you.

Can't I Just Ostrich This Thing a Little Longer? Philipp Stiefel has the most comprehensive tutorial for upgrading API declarations at: Windows API declarations in VBA for 64-bit.

You can't simply do a find and replace of Long with LongPtr in all of your Declare statements. There is no across-the-board rule for how to update every API declaration from VBA 6 to VBA 7. However, if the VBA 6 Long argument actually refers to a memory address, then the argument should be declared as a LongPtr in VBA 7. If the Long argument of an API function represents a plain old number, then it should remain declared as a Long integer in VBA 7. All memory addresses were 32 bits long.īeginning in VBA 7, you can begin to update your API declarations. In VBA 6 and earlier, there was no need to distinguish between a long integer that referred to a memory address and a long integer that referred to a plain old number.
