Bug 7020

PowerScript Handle function returns incorrect datatype in 64-bit 11 October, 2021

John Fauss
27 July, 2021
Product: PowerBuilder Category: PowerScript
Version: 2019 R3 Build: Any
Classification: Sybase (legacy) bug Publishing: Public
Priority: P3
Status: Scheduling Reason:
Mark Lee @Appeon 29 July, 2021
#4
Hi John,

Yes, the PowerScript Handle function currently returns a Longptr datatype.
If you encounter issues that it returns Long datatype, etc. in the future, please submit a ticket and also attach a reproducible case for us. Thanks in advance.

Regards,
Mark Lee
John Fauss 28 July, 2021
#3
Thank you very much for the very quick response, Mark!

Are you stating the PowerScript Handle function currently returns a value of type Longptr and that only the documentation needs to be corrected?

The reason I wish to clearly understand is because I help answer some of the questions raised in the Appeon Community Q&A regarding interfacing PB to the Windows API, and I wish to clearly and accurately respond whenever a question comes up regarding Windows handles. There is a significant misconception about handles in the development community; that they are always 32-bit integer (long) values. I know that this is NOT the case in a 64-bit process. The documentation of the Handle function having been incorrect since 64-bit support was added has only fueled this misconception.

If the PowerScript Handle function is currently returning a Longptr, I can let people know that all they should need to do is use the proper datatype. 

If the PowerScript Handle function is currently (and incorrectly) returning a Long, I can tell people this is a bug that MAY cause them to experience an issue, and that it will be fixed in the near future. Regardless, I know that the Longptr datatype should ALWAYS be used in code whenever a Windows handle is involved, be it a variable, an argument value to an external WinAPI function, or a structure element.
Mark Lee @Appeon 28 July, 2021
#2
Hi John,
 
Thanks for reporting this problem.
We will correct the descriptions of the Handle function in the documentation, the datatype it returned should be Longptr. And the description of the Longptr datatype (refer to the link below) should be the same as what you have provided.
https://docs.appeon.com/pb2019r3/application_techniques/ch09s03.html 

I guess you want to know how to pass PowerBuilder structures to external C functions, if yes, you can refer to the following link for detail.
https://docs.appeon.com/pb2019r3/powerscript_reference/ch01s03s04.html

BTW, you can directly use the Longptr datatype instead of the long datatype in your 64-bit or 32-bit application and it should work well.
If the issue persists, we recommend you provide a reproducible sample test case (including the PBT/PBL) for us to reproduce on our side. Thanks in advance.

Regards,
Mark Lee
Hi John,

Thanks for noticing and reporting to us this issue.
I'm gonna transfer it to main Support/Engineering team for their review and input on the matter.

Regards,
Francisco
John Fauss 27 July, 2021
The Handle function returns the Windows handle of a PowerBuilder object. In a 64-bit process, a Windows handle is a 64-bit integer, not 32-bit. The PowerScript function should return Longptr, not Long.

This is not simply a documentation bug. In the Windows API, the various handle-related type definitions resolve to HANDLE, which is another type definition that resolves to PVOID, which is yet another type definition that resolves to "void *"...a pointer (i.e., memory location) to any type of data.

Source: https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types

Even though the value of a handle is an ID, the datatype of a handle in the Windows API is a pointer, so its size corresponds to the process bitness, either 32-bit or 64-bit. The memory utilized by a Windows handle in 64-bit aligns on an 8-byte boundary, not a 4-byte boundary.

This is a legacy bug that goes back to PB 12.6, but has never been addressed. As the generation of 64-bit applications becomes more common and popular, the need to correct this oversight grows.
OS:
All
Platform:
64-bit
Database Type:
Database Version: