To continue with this content, please log in with your Data Access ID or create a new account.
Cancel Data Access ID
You may not be authorized to see this content. Please contact Data Access Europe for more information.
Cancel Data Access Europe
You are not authorized to see this content.
Cancel Data Access Europe
Next lesson:
External APIs
Cancel

Migrating to DataFlex 2021, Part 3

Lesson 13 – Language Changes


This lesson focuses on language changes in DataFlex 2021. Several datatypes have been changed due to 64-bit, and the datatype, Longptr, has been added. In 64-bit compilation, the Pointer datatype size is 64 bits. In previous DataFlex versions, the Pointer was a replacement integer. This has changed; the Pointer is now identical to the Address type. 

In DataFlex 2021, both Pointer and Address are true memory address types, which means it is 32-bits in size in 32-bit compilations and 64-bits in size in 64-bit compilations.  It is recommended to use Pointer. Packages have also been changed, so that they only use the Pointer type. Address can be kept if that is the preference.

The Integer type is still 32-bit even in a 64-bit compilation. One of the most common problems with converting to 64-bit, is that the Integer type is used in the source to hold a Pointer value, but a 64-bit Pointer does not fit in an integer. This is called Pointer truncation. This will have to be corrected anywhere this is done in the code.

In DataFlex 2021, a new datatype has been created, called Longptr. This is an integer type that is the same size of a Pointer (32-bit on 32-bit and 64-bit on 64-bit), so this integer type can hold a Pointer. Longptr is normally not needed but may be useful for lower-level coding. It may be useful when interfacing an external API or a Windows function, or when calculating with Pointers.


DEMONSTRATION

  • Shown here is a define for a Longptr constant and a Longptr datatype. Note that the single character identifier is the letter “P”. A Pointer can be moved to Longptr and back again without issue.
  • An integer datatype stays the same on 64-bit, it is still a 32-bit type. This means that in 64-bit mode, a Pointer does not fit in an Integer. The reverse, moving an integer to a pointer type, is allowed, but generally makes no sense.
  • If this is compiled as 64-bit, the compile error results at line 040. It will compile in 32-bit, but that is not an indication of good code. There will be problems if it needs to be complied in 64-bit at some point. Using the Pointer or the Longptr type will correct this.
  • Note that not all conversions from Pointer to Integer are found by the compiler. This is due to DataFlex being a loosely typed language. The compiler only has limited knowledge of data types. If a conversion from Pointer to Integer is still in the code, then it will cause a runtime error, whether or not overflow will happen, when run in 64-bit.
  • Running this program in 64-bit shows an illegal datatype conversion error at line 045.
  • Pointer to Integer conversions need to be searched for since they are not all detected by the compiler. Keywords such as Pointer, Address or AddressOf can be searched for.
  • There are a few more data type changes.
  • There is an unsigned version of the Longptr, ULongptr. It is an unsigned integer type that is the same size as a Pointer.
  • The Handle datatype has changed from an alias for Integer to an alias for Longptr. This was done because the Handle datatype on 64-bit Windows is 64-bit size. Note that Handle should not be used for Pointers.
  • The OLE_Handle datatype alias was used as an alias for Handle, but it has been changed to be an alias for Integer because it is always 32-bit in Windows.
  • Here is an overview of alias datatypes in DataFlex 2021. Note that the new Longptr datatype is a true native datatype, not an alias.