1. Erwin Milke
  2. PowerBuilder
  3. Thursday, 25 June 2020 16:48 PM UTC

Hello guys

I'm trying to read file size, modification date and file type from all files in a given path.

The idea is to simulate a Windows Explorer inside a PB window. 

I'm not aware of an object or function inside Appeon, so I will use any of the following APIs from Kernell32.dll 

  • GetfileSize
  • GetFileInformationByHandle

 

For simplicity, I will use GetFileSize

I declared the external global function GetFileSize as:

Function long GetFileSize (long hFile, double lpFileSizeHigh) Library "Kernell32.dll"

 

I open the file with ll_file = fileopen(filename)  ( ll_file declared as long )

I get "Bad runtime function reference" error. 

I assume "long Hfile" is a bad variable declaration, but don't know how to declare it inside PB as docs.microsoft.com shows:

Should it be an structure data type instead of long?

Thanks for the feedback

 

Accepted Answer
Erwin Milke Accepted Answer Pending Moderation
  1. Friday, 26 June 2020 15:35 PM UTC
  2. PowerBuilder
  3. # Permalink

Thanks again Chris !!

Please help me to clarify the following: I guess I'm losing something here  embarassedembarassed

 

Following is the code in my window to call this API:

Global External Function Declaration:

Function ulong GetFileSize( ulong hFile, ref ulong lpFileSizeHigh) Library "Kernel32.dll"

 

Code inside calling window:

ulong lu_result, lu_file, lu_size

string ls_file_name = "a valid and existing file name"

lu_file = fileopen(ls_file_name, streammode!, read!)   // File is 14KB size, lu_file is 1, or 2, or a valid handle

lu_result = Getfilesize(lu_file, lu_size)

fileclose(lu_file)

 

lu_size always returns 0 ( not needed because the file size is small )

I noticed that lu_result ALWAYS returns 4294967295, even if I do NOT open the file with fileopen()

As I read about the Windows DataTypes, dword is a 32-bit unsigned integer with a range between 0 and 4294967295

If the WinApi Function GetfileSize() succeeds, it will return the low order double word of the file size.

The second parameter of the function is a reference to the higher part of the file size. 

 

Questions:

  1. Do I need to use a specific filehandle created with the Windows API Createfile() o Openfile()?
  2. Once the code runs well, what do I have to do with the ulong result to convert it to the actual filesize?

 

Following is the Winapi Getfile() syntax from https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfilesize

 

Sorry to keep you busy guys cool

 

Comment
  1. John Fauss
  2. Friday, 26 June 2020 18:16 PM UTC
A PowerBuilder file "handle" and a Windows "handle to a file" are NOT the same thing.

The first is a 16-bit integer value (typically, a very small number) that PB assigns to a file you open so that you can easily refer to it in other PB functions.

The second is a 32- or 64-bit integer (as are all Windows handles) that Windows assigns so that you can refer to the file in other Windows API functions.



I'll reiterate my earlier suggestion to download and examine the FileSys free sample application that Roland Smith graciously provides to the PB community. While I commend your desire to get this to work on your own, I think you would learn as much or more with less effort and frustration by looking at the code in Roland's small app. However, the choice is yours. of course. Good luck!
  1. Helpful
  1. Erwin Milke
  2. Friday, 26 June 2020 21:16 PM UTC
Just now I've got your point John !!!



I downloaded and created the library for the FileSys tool from Roland Smith's web page.

It's beautiful !!!

It cleared up all my doubts and opened my eyes to new stuff I was not aware of.



That tool is exactly what I was trying to implement

Thank you so much again guys !! ( John, Chris and Roland !!! )
  1. Helpful
There are no comments made yet.
Erwin Milke Accepted Answer Pending Moderation
  1. Friday, 26 June 2020 14:36 PM UTC
  2. PowerBuilder
  3. # 1

Thanks so much for your advices John. I will take a look to the zip file. First I will clarify some doubts on the function declaration

 

Comment
  1. John Fauss
  2. Friday, 26 June 2020 15:32 PM UTC
You're welcome! Quick note: If you use the Longptr datatype for both arguments in the GetFileSize API declaration, then it will work when compiled for either 32-bit or 64-bit because Windows handles and pointers are 8 bytes long in a 64-bit execution environment:

FUNCTION ulong GetFileSize ( longptr hFile, ref longptr lpFileSizeHigh ) LIBRARY "kernel32.dll"

Good luck!
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 25 June 2020 19:21 PM UTC
  2. PowerBuilder
  3. # 2

Hi Erwin;

  FWIW: Is use the declaration ...

FUNCTION ulong GetFileSize ( ulong hFile, ref ulong lpFileSizeHigh) LIBRARY "kernel32.dll"

HTH

Regards ... Chris

Comment
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Thursday, 25 June 2020 18:19 PM UTC
  2. PowerBuilder
  3. # 3

Greetings, Erwin - 

I suggest you examine the "FileSys" free code example on Roland Smith's TopWizProgramming web site, as it should be very helpful:

https://www.topwizprogramming.com/freecode_filesys.html

In regards to translating Windows typedef'd data types to PB equivalents, please look at a recently-published, four-part series of tutorials on how to interface PB to the Windows API that is available in the PowerBuilder Tutorials section of the Appeon Community:

https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder

In particular, Part 4 includes translation tables for these kind of data type conversions. Have a look!

Regards, John

Comment
  1. Erwin Milke
  2. Friday, 26 June 2020 15:43 PM UTC
Great documentation work for your tutorials John !!! thanks for that !

Lots of great examples !!
  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.
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.