Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (3)

Resolved FindFirstFileA Windows API works on WIN7 but not WIN10

  1. Issue
0
Votes
Undo
  1. David Haas
    David Haas
  2. PowerBuilder
  3. Thursday, 19 December 2019 15:03 PM UTC

Hello,

We're moving PB 2017 application from WIN7 to WIN10.  One of the processes in that app is to process files in a given directory/folder.  Currently on WIN7 we use 'FindFirstFileA' WIN API to start the processing which works....returned value/handle is > 0.

However when I try running app on WIN10 box,  the 'FindFirstFileA' returns value of -1.

I'm stuck here and all of our PB apps need to be moved off of WIN7 to WIN10 right after beginning of 2020.  If anyone could shed some light on this for me or provide suggestion that would be much appreciated!!!!

Thanks, Dave

REST-Client PB 2017
PowerBuilder crash debug
Responses (3)
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 8 January 2020 21:23 PM UTC
  2. PowerBuilder
  3. # 1

Hi David;

     FWIW: You should never use the "A" or "W" in your method's name declaration. Instead, use the "ALIAS" syntax. For example ...

Function long FindFirstFile ( Ref string filename, Ref win32_find_data findfiledata ) Library "kernel32.dll" Alias For "FindFirstFileW"

  That way, your PB PowerScript code would never have to change!   ;-)

Food for thought.

Regards ... Chris

 

Comment
Michael Kramer
  1. Michael Kramer
  2. Thursday, 9 January 2020 10:39 AM UTC
Agree with Chris, this is preferred naming. Who knows, maybe in a few years we have a 128-bit super-uni-code version named FindFirstFileX . . .

My strategy is actually always use NVOs to encapsulate Win API calls. Every external function defined as PRIVATE EXTERNAL function. Hence, I have a of_FindFirstFile. In "my" facade NVO's public functions I perform whatever preprocess and postprocess that may be required. Like pre-allocate PB VM memory for pass-by-REF parms or conversion between API specific date/time formats to PB's internal date/time formats.

Encapsulate to prevail in this interconnected myriad of apps and APIs.
  1. Helpful
There are no comments made yet.
David Haas
David Haas Accepted Answer Pending Moderation
  1. Wednesday, 8 January 2020 20:06 PM UTC
  2. PowerBuilder
  3. # 2

Thanks Michael!  Just getting back to this.... So I think I understand what you're saying....I may have it working now both ways.


I Tried  FindFirstFileA in the declaration of Global External Function
    Function long FindFirstFileA(ref string filename, ref str_finddata filedata) Library 'kernel32.dll'
       Added 'alias for "FindFirstFileA;Ansi" ' after and it worked....kept it off and it didn't

I Tried  FindFirstFileW in the declaration of Global External Function
    Function long FindFirstFileW(ref string filename, ref str_finddata filedata) Library 'kernel32.dll'
       Added 'alias for "FindFirstFileW;Ansi" ' after and it didn't work ....kept it off and it did work

Is that what you would expect to happen? 

Now that I have both options that work, wondering if I change to FindFirstFileW.  If I do,  I need to go through all code and change 'A' to 'W'.  If I keep at FindFirstFileA,  I just need to modify declaration in Global External functions...a lot less changes.

Suggestion?

Comment
Load more comments
David Haas
  1. David Haas
  2. Wednesday, 8 January 2020 20:51 PM UTC
Thanks Chris! So I'll have number of places to make this change in a handful of apps.



So any "xxxxxxxxA" calls, I should change to "xxxxxxxW" (i.e. GetTempPathA, GetCurrrentDirectoryA etc.)?



Will I need to do anything with other functions that don't have the "A" at the end (i.e. OpenProcess, FileTimeToLocalFileTime, WaitForSingleObject)?
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 8 January 2020 21:19 PM UTC
Any method that does not end in an "A" in the method name is OK to leave "as is" (or have the ";ANSI" extension).
  1. Helpful
Andrew Barnes
  1. Andrew Barnes
  2. Friday, 10 January 2020 23:58 PM UTC
Adding the ;Ansi to your global external function declaration is the easiest solution.

Chris's suggestion of using the alias such that you call FindFirstFile in PowerScript while declaring FindFirstFileW as an alias is a distinctly better solution.

Michael's suggestion of wrapping the WinAPI calls in an NVO is probably the best solution. The FindFirst family of functions really lend themselves to that nicely. The NVO route allows you to hide all sorts of annoying code keeping the script calling it much cleaner, as well as guaranteeing that you never forget to call FindClose when you are done with the handle.
  1. Helpful
There are no comments made yet.
Michael Kramer
Michael Kramer Accepted Answer Pending Moderation
  1. Thursday, 19 December 2019 16:20 PM UTC
  2. PowerBuilder
  3. # 3

Hi David,

I'm surprised that the ANSI version fails. Have you marked it ";ANSI" to ensure proper interop with PB's Unicode strings?

I've been using FindFirstFileW for many years because that is the Unicode version. So no need for character conversions - and it supports extended file paths starting Win10, #1607.

HTH /Michael

Comment
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.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.