1. jalil Rehman
  2. PowerBuilder
  3. Wednesday, 3 July 2024 12:15 PM UTC

Hi Folks 

Environment : PB 2022 R3 64 bit

Here is the sample code snippet where  the application crashed in 64 bit but not in the 32 bit

but if I change the variable type Long to LongPtr or LongLong ,  the application does not crash.

confusion is that what to use and why ? either LongPtr or LongLong

as Sometimes message.longparm is used to pass a number (which in theory could also be negative), and sometimes a memory address of a string.

 

Sample code 

event ue_select;long ll_wordparm, ll_longparm

ll_wordparm = message.wordparm
ll_longparm = message.longparm

String is_title =String(ll_longparm, "address")

end event

 

Debugger values in 64 bit environment when message.longparm passed as a reference (memory address of a string)

 

The Appeon docs say message.longparm = Long 

but the debugger reveals it as LongPtr.

what should be the variable ll_longparm  like ? longptr or LongLong ?

 

Thanks 

 

Who is viewing this page
Roland Smith Accepted Answer Pending Moderation
  1. Wednesday, 3 July 2024 17:33 PM UTC
  2. PowerBuilder
  3. # 1

Quick answer: Longptr represents Long in 32-bit apps and LongLong in 64-bit apps. The compiler automatically chooses the correct datatype based on the bitness of the app.

Comment
There are no comments made yet.
Francisco Martinez @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 3 July 2024 14:21 PM UTC
  2. PowerBuilder
  3. # 2

Hi Jalil,

 

This is indicated as a necessary step when migrating you applications from 32 to 64 bit. Please see the following documentation: https://docs.appeon.com/pb2022/migrating_32bit_applications_to_64bit/header-n171.html

 

Regards,
Francisco

Comment
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Wednesday, 3 July 2024 14:19 PM UTC
  2. PowerBuilder
  3. # 3

Hi, Jalil -

In a 64-bit version of Windows (which most are anymore), addresses are 64-bits (8 bytes) long. Because the WPARAM and LPARAM argument values in a Windows message can and frequently do contain a memory address, they are also 64-bits in length.

Correspondingly, the datatype of the WordParm and LongParm properties of the PB Message object were changed to Longptr in order that no data truncation occurs when your PB app is compiled as a 64-bit application. The documentation in PB Help is incorrect and needs to be corrected.

You should use the Longptr datatype in your application whenever a variable may contain a memory address or a Windows handle. By doing so, the PB compiler will use the correctly-sized variable (four or eight bytes long) for the bitness of the compiled application. If this were not available, then you would need to check the application's bitness in code (via the ProcessBitness property of the Environment object) and use either a Long/UnsignedLong or LongLong variable.

Best regards, John

Comment
  1. John Fauss
  2. Wednesday, 3 July 2024 14:28 PM UTC
FYI - I have opened public bug ticket 12261 regarding this documentation error.
  1. Helpful 2
  1. Armeen Mazda @Appeon
  2. Wednesday, 3 July 2024 17:21 PM UTC
Thanks John for opening bug ticket for this!
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.