In 64-bit, it is a MANDATORY keyword….that still has absolutely no effect! In 32-bit Office 2010 this is an optional keyword that has absolutely no effect. Since sending a DLL with the wrong size value can be a REALLY bad idea, Microsoft introduced a new keyword to the declaration statement called PtrSafe. API/DLL CallsĪs I stated earlier, the LongPtr data type will most often be needed in API or DLL calls requiring pointers or handles (to windows, or processes, or code in memory, or….well A LOT OF STUFF). This is HIGHLY annoying because it means you cannot simply find/replace Long with LongPtr to “update” code. One small catch with the LongPtr data type is that although it IS either a Long or a LongLong, because it is intended for pointers and handles only VBA will NOT ALLOW you to perform arithmetic functions on it (such as using it in a loop). This allows you to “easily” write code that will work between both 32 and 64-bit Office installations (as long as they are both 2010+). At compile time this will BECOME a 64-bit number on Office 64-bit (LongLong) and a 32-bit number on Office 32-bit (Long).

Helpfully Microsoft has added a new data type in VBA 7 (Office 2010) called a LongPtr. Unfortunately previous versions of Office (2007 backwards) do not have a data type that holds a 64-bit value, and in 2010 32-bit, you don’t want one! Fortunately VBA uses VERY few pointers 95% of them are involved in API or DLL calls. The main difference between 32 and 64-bit Microsoft Office (VBA wise) is that any pointers now need to be 64-bit rather than 32. There are actually very few issues with moving code from 32-bit Office to 64-bit Office, but a couple of them are significant. If you don’t care about reasons or explanations, skip to the summary to see how to avoid or fix the issues. It’s the first time this has been an issue, and I thought I’d detail some of the effects. In the last week I’ve had a client upgrade to 64-bit Microsoft Office and it has caused some havoc with parts of my VBA.

Use ms office 32bit or 64bit?