On Jan 26, 2008, at 12:46 PM, Joe Lertola wrote: > > On Jan 26, 2008, at 2:28 PM, Brian Stevens wrote: > >> >> On Jan 26, 2008, at 8:29 AM, Joe Lertola wrote: >> >>> Also I am puzzled as to how this function returns information. >> >> Information (in this case the FSRef of the found file ) is >> returned via the outRef pointer. A pointer is passed to the >> function (outRef as ^FSRef), so copying (via blockmovedata) the >> data to the pointer effectively returns the data to the caller. Of >> course, the "caller" in some cases is the same function since this >> is called recursively. One way to study recursion is to walk >> through the demo code in the debugger (use the FB version not the >> FBtoC version) and look at the call stack and notice how >> IterateFolder calls itself. >> > > Thanks Brian. Would a version of Fn IterateFolder be a good > replacement for USR ScanFolder? Possibly. That is my code and it was written quickly. Look for bugs. > > >>> You use BlockMoveData in the middle of a loop. Doesn't this >>> result in the return of only the FSRef found? >> >> >> I'm not sure what you are asking. Yes, it returns only the FSRref. >> If you are questioning the use of BlockMoveData versus some other >> method, you're right there are other methods. I like BlockMoveData >> because it is clear what is going on and as a TB call it won't >> break if some future FB syntax is not supported. It also adapts >> transparently to any size changes in the FSRef by Apple. If this >> isn't your question, please ask again. >> > I was referring to the version of Fn IterateFolder which Steve > posted this morning. It lacks the code that checks for the file > name so so it looks like it returns a FSref on every run through > the loop. The code Steve posted is an excerpt from my demo. See my old posts for links to download the full demos. Brian S.