Hello All,

We are preparing for dual platform 64 / 32 bit deployment. "What's New" documentation describes changing handle datatype to LongPtr

The longptr datatype is 4 bytes in the 32-bit platform and 8 bytes in the 64-bit platform. In the 32-bit platform, longptr is the same as long; you can continue using long wherever longptr is required in 32-bit applications. In 64-bit applications, however, using long to hold longptr variables will lead to data truncation from 8 bytes to 4 bytes, or memory corruption if you pass a long ref variable when a longptr ref is required. If you want to move to 64-bit, use longptr wherever required. It does no harm to 32-bit.  

Later on the doc does say " If you want to represent/compute 8-byte long integers, use longlong"

First off in testing I discovered a nasty bug. "SAP created cr806730 for this issue - calling external function that is returning a longptr, in 64-bit, application returning 0."  At the current time, longptr does NOT work!

In the interim, SAP support suggested using LongLong as external function parm types and to capture returned handles.  But since LongLongs are 64-bit *signed* integers and LongPtr is a 'pointer type', that is supposed to be cross platform compatible, I am unsure of the ramifications of the change.  I don't want to have to refactor our code twice.

I did find this in MS documentation: •Pointer Truncation—Although a 32-bit application can use the LONGLONG data type to store a 64-bit value, there are instances where no Windows API element exists that would enable the 32-bit application to receive a 64-bit value from a 64-bit process, or to send a 64-bit value to a 64-bit process.

My question: Is possible to always use LongLong instead of LongPtr?  Is there any reason not to do so?

Thanks for sharing your knowledge on this subject

Yakov