Hey everybody,
Is there a way to get a quick count of files (and sub-dirs) in a directory? Thing is, I wanna read all the file names in memory but I need to know how much memory to commit first right? I have come up with two ways of doing it but neither one seems very good to me:
1) everytime I add a file name check to see if I've run out of memory in the block of memory I'm using. It works, but it isn't "neat"
2) run through FindFirstFile/FindNextFile to get a count of files. But then I'll just have to run through the whole thing again to get the actual job done.
I checked through the APIs and didn't see anything. I searched the board. Didn't find anything there either (well, I found method #2)
PS While I'm at it... Does anyone know the most data that can be read from disk in *one* seek. I mean, files aren't read byte-by-byte, their read in chunks. What's the size of one "chunk" and can I get this value from APIs? Obviously.. .this must change from HD to HD...
Thanks a lot
--Chorus
Is there a way to get a quick count of files (and sub-dirs) in a directory? Thing is, I wanna read all the file names in memory but I need to know how much memory to commit first right? I have come up with two ways of doing it but neither one seems very good to me:
1) everytime I add a file name check to see if I've run out of memory in the block of memory I'm using. It works, but it isn't "neat"
2) run through FindFirstFile/FindNextFile to get a count of files. But then I'll just have to run through the whole thing again to get the actual job done.
I checked through the APIs and didn't see anything. I searched the board. Didn't find anything there either (well, I found method #2)
PS While I'm at it... Does anyone know the most data that can be read from disk in *one* seek. I mean, files aren't read byte-by-byte, their read in chunks. What's the size of one "chunk" and can I get this value from APIs? Obviously.. .this must change from HD to HD...
Thanks a lot
--Chorus
There's one API that might be your friend :: DlgDirList - You need a list box though to get this working(You can create a hidden listbox and work from there -> cheap and cheating :) ). Then you can count the number of items on the listbox, allocate ... OR you could do a linked list then use FindFirstFile...
As for your P.S. question...no idea sorry :(
As for your P.S. question...no idea sorry :(
Hey Stryker,
Thanks for the ideas.
Problem is this: the strings all end up going to a owner-drawn list box anyways. Now, I'd just use LB_DIR or DlgDirList or something *but* windows 9x has this annoying habit of filling the list box with "" type strings. So I'm using FindFirstFile, etc to get the long file names (w/o the parenthesis on directories). Also, I'm not declaring the list box as LBS_HASSTRINGS cause I find the data returned by FindxxxFile pretty useful. So I just store the pointer to the struc in the list box and handle the mem allocations myself... which of course brings me back to the original question.
:(
You'd think it'd be simple like GetCountOfFiles or something :)
Thanks again
--Chorus
Thanks for the ideas.
Problem is this: the strings all end up going to a owner-drawn list box anyways. Now, I'd just use LB_DIR or DlgDirList or something *but* windows 9x has this annoying habit of filling the list box with "" type strings. So I'm using FindFirstFile, etc to get the long file names (w/o the parenthesis on directories). Also, I'm not declaring the list box as LBS_HASSTRINGS cause I find the data returned by FindxxxFile pretty useful. So I just store the pointer to the struc in the list box and handle the mem allocations myself... which of course brings me back to the original question.
:(
You'd think it'd be simple like GetCountOfFiles or something :)
Thanks again
--Chorus
Use FindFirstFile, FindNextFile ... that's the best solution to count files .... :)
Use a linked list, it's a handy data structure when dealing with an
"unknown" amount of items.
For IDE hard drives, the data unit size (sector size) is 512 bytes,
and it's like that on all drives (this is a logical size though, the
harddrive might be structured internally in "whatever" way, but
when you program the IDE controller, you work with 512byte
chunks).
"unknown" amount of items.
For IDE hard drives, the data unit size (sector size) is 512 bytes,
and it's like that on all drives (this is a logical size though, the
harddrive might be structured internally in "whatever" way, but
when you program the IDE controller, you work with 512byte
chunks).
the max file name or dir name is 255 chars.
260, actually... at least thats what _MAX_PATH says.
Qages,
Thank you , but the point is I need to know *how many* 260 byte allocations to make (and yes, MAX_PATH=260). And this is exactly related to the number of files in a directory
Fodder, as for link lists, I think that leaves me with the same problem. I still need to allocate an appropriate chunk of memory to hold the number of entries. Thanks though,
Thank you , but the point is I need to know *how many* 260 byte allocations to make (and yes, MAX_PATH=260). And this is exactly related to the number of files in a directory
Fodder, as for link lists, I think that leaves me with the same problem. I still need to allocate an appropriate chunk of memory to hold the number of entries. Thanks though,
The lovely thing about a linked list is that it's a "dynamic" structure...
you just keep on allocating memory for additional items, and
"link it" into the list...
you just keep on allocating memory for additional items, and
"link it" into the list...
Qages,
Thank you , but the point is I need to know *how many* 260 byte allocations to make (and yes, MAX_PATH=260). And this is exactly related to the number of files in a directory
in your code to find the files/dirs, it should loop every time one is found, just count the loops.?