>Dragan,
>
>Just create a FileHandle class that lightly wraps the LLFF and keeps the handle in one of its properties. When it goes out of scope it can FClose() automatically in it's Destroy() method.
>
>I think the output of LIST STATUS can be parsed for file handles.
>
>>Assume you have a routine where you Fopen() or Fcreate() several files, and it breaks. You cancel it. The variables where the file handles were are lost. You issue Display Status, and the file handles, along with file names, are displayed (among other info, of course).


It sure is something I (should)'ve thought of, for future apps. For one, I'll need it to keep my often used things like parsing ascii files, replacing text within files etc. It'll be kind of neat to have it all handled by one custom class, and calll FileHandle1.GetOneLine and such instead of writing Do While !feof(gfh).
The GFH stands for Georg Friedrich, of course :)

For now, I'm just having lots of legacy (my own) to port, which means there's a lot of code being written without an idea of what it could look like if ever I decided to make it neat (i.e. LL functions are used ad hoc, no system in it), and, besides, the situation I've described actually happens during development - and this is probably an overkill approach for that task. I've also thought of capturing the List Status output, but that's overkill too - would need at least couple of hours to make out (but once I think I'll need the detailed list, I'll surely have to do that). For my needs, what Dore Svei suggested is exactly what I need. Btw, what's the lowest file handle number to start with? In FPD I seem to remember it always began with 10 or 11, lower numbers being reserved for various low-level things (like printer, .tmp file handles etc) and were a strict no-no to touch. What's the lower limit now.

A more important thing: are we sure that the new file handle number will be higher than all the other numbers previously used? How do we know VFP won't recycle them?