Forum unknown
· Programming
AmigaDos questions
11 messages in this thread
thank you. tree will do nicely, i'm having a tantrum with myself for not
thinking of the hack that TREE used. i am just too concerned with coming up
with a “minimal code–elegant hack'' to have thought of his approach. does
YOUR directory walker use straight recursion or do you follow TREE's example
and record subdirectories for opening later? i was dropping down into a
recursion whenever i saw a subdirectory and hoping ExNext would remember my
context correctly. thanx again for taking the time/money to reply. sdp
I think you almost had your recursive solution from the sounds of it. The key
is to save the context as you suggested. Each time you find a new directory
and are going to call Examine(), you must allocate a new block of memory for
your FileInfoBlock.
When the end of the directory is encountered and you are going back down the
tree one level, de-allocate the block and start using the previously
allocated block that you were using for the directory. It's pretty slick and
easy and actually works under MS-DOS. I haven't tried it on the Amiga, but
it should work.
i think there might be something slightly amiss in the way IoErr works
because sometimes my original directory walker worked fine. just certain
disks would get finished too early… for lack of explicit knowledge of
how to look further into IoErr, and because there was an easy work around
in TREE.c, I hacked Tree's algorithm (if directory type, remember name for
later directory walking.) i did as you suggested with the FileInfoBlock,
(least i think i did, memory is getting fuzzy, now.) and it didn't seem to
be enough context for it. thanx for your time. sdp
To tell you the truth, I've never tried the IoErr() function. All I use is
the status return from the Examine() and Next() functions. Using the
status returns and information in the InfoBlock if the status is clean
seems to work correctly for me (however I'm not crawling up and down the
tree as you are).
To tell you the truth, I've never tried the IoErr() function. All I use is
the status return from the Examine() and Next() functions. Using the
status returns and information in the InfoBlock if the status is clean
seems to work correctly for me (however I'm not crawling up and down the
tree as you are).
i think there might be something slightly amiss in the way IoErr works
because sometimes my original directory walker worked fine. just certain
disks would get finished too early… for lack of explicit knowledge of
how to look further into IoErr, and because there was an easy work around
in TREE.c, I hacked Tree's algorithm (if directory type, remember name for
later directory walking.) i did as you suggested with the FileInfoBlock,
(least i think i did, memory is getting fuzzy, now.) and it didn't seem to
be enough context for it. thanx for your time. sdp
I think you almost had your recursive solution from the sounds of it. The key
is to save the context as you suggested. Each time you find a new directory
and are going to call Examine(), you must allocate a new block of memory for
your FileInfoBlock.
When the end of the directory is encountered and you are going back down the
tree one level, de-allocate the block and start using the previously
allocated block that you were using for the directory. It's pretty slick and
easy and actually works under MS-DOS. I haven't tried it on the Amiga, but
it should work.
My routine does straight recursion, but allocates a new FIB each time. I will
send it up ARCed with some other useful stuff.
My routine does straight recursion, but allocates a new FIB each time. I will
send it up ARCed with some other useful stuff.
Check DIRS.ARC when it shows up. Also includes a routine to print the current
directory as a string (like CD w/o args). Could be expanded to take any file
name and give back full path.
Check DIRS.ARC when it shows up. Also includes a routine to print the current
directory as a string (like CD w/o args). Could be expanded to take any file
name and give back full path.