I'm new to PB, while debugging is see FindFirstFileW(as_FileSpec, lstr_FindData) returning negative value ?
Any help would be appreciated.
Thanks
I'm new to PB, while debugging is see FindFirstFileW(as_FileSpec, lstr_FindData) returning negative value ?
Any help would be appreciated.
Thanks
Hi, Aurangzeb -
Rather than guessing. it would be very helpful if you would please post the following:
1. The external function declaration(s) you are using for the FindFirstFileW Windows API function.
2. The exported syntax for the PB version of the WIN32_FIND_DATAW structure used by the FindFirstFileW API function.
3. The exported syntax for the PB version of the FILETIME structure contained within the PB version of the WIN32_FIND_DATAW structure.
I see in your original post that you included the tag "64-bit"... can you confirm that you are indeed needing to execute this API function as 64-bit? The structure layout may differ significantly between 32-bit and 64-bit.
Are you wanting/needing to run your app from the PB IDE? This will be 32-bit unless you are using PB 2022 and have chosen to run the app as 64-bit from within the PB IDE. This is why it is almost always helpful to know exactly what version, release and build of PB you are using - so please state this information.
Best regards, John
Is the overall goal to produce a 64-bit version of this application?
If so, you've got a significant challenge ahead of you... This app appears to use a very old version of the PowerBuilder Foundation Class (PFC) libraries. I can tell that from the "Copyright 1996-2000" in the comment header and because the PFC was open-sourced after PB version 8 and the Sybase copyright notice was replaced an Open Source notice.
The challenge is going to be that your old copy of the PFC libraries does not support 64-bit execution. 64-bit support was not added to PowerBuilder until version 12.6, so you'll need to use a newer version of the PFC libraries.
I see in the code you posted that the ll_handle variable declaration has been updated to use the Longptr datatype (which was added to PB in version 12.6) instead of Long, which is correct. However, the external function declarations that tell PB how to interface with external DLL functions (such as the FindFirstFileA Windows API function and the FindNextFileA API function later in the same of_DirList function) may need to be inspected/modified to support 64-bit execution - along with several others which are called from the PFC's "file service" objects.
Thanks to the underlying differences in 64-bit execution from 32-bit, simply re-compiling a PB app that interfaces with Windows API functions is not sufficient. There is code refactoring that may be needed, and in fact WILL be needed because the version of the PFC libraries used by this app is so old.
PB was changed internally from ANSI to Unicode in version 10, so the PFC was modified near the same time to use the Unicode version of the Windows API functions (FindFirstFileW instead of FindFirstFileA). The ANSI flavor of API functions can still be used, but each external function declarations in PB must be changed to explicitly note that it uses ANSI and not Unicode. More refactoring.
This is a much bigger issue than can be addressed in this Q&A forum.
Here is a link to some guidance on migrating a PB application to 64-bit:
https://docs.appeon.com/pb2022r2/migrating_32bit_applications_to_64bit/index.html
Since you are new to PowerBuilder and relatively inexperienced in PB, I have two suggestions:
1. Do not migrate the application to 64-bit... leave it as a 32-bit app. Or...
2. Utilize an experienced PB consultant to update your app with the current version of the PFC, and only then convert the app to 64-bit.
Good luck!
Hi Aurangzeb,
According to Microsoft's docs:
If the function fails or fails to locate files from the search string in the lpFileName parameter, the return value is INVALID_HANDLE_VALUE and the contents of lpFindFileData are indeterminate. To get extended error information, call the GetLastError function.
INVALID_HANDLE_VALUE has a value of -1, so that might be the result you're getting.
Regards,
Francisco
Please answer point 1., 2. and 3. of John's question. It's going to be hard to help you if you don't.
regards.