>We have a program that goes though all our source code, over 2500 files, and searches for a string. It creates a text file that contains the entire command that the string is in and the line number in the code that its on. It would be nice to have the text file have the line numbers going from bottom to top so if we modify line it doesn't though off the rest of the line numbers when we find the next match. Maybe it's easier to write the text file in desending order than go backwards in a file.
The other thing is that we have the option to print X number of lines before and after the find. So I always have to go back to find the X number of lines before hand. This program is make use of the low level file function for almost all of the searching and it would be a big deal to turn it into an array based - plus I don't know how much of a proformace hit it would take.

If the change to an array is too difficult, you could write your output to a simple DBF and then index or sort it, browse it, print it, etc.

The "keys" could be: program id/file name, "occurance", line number.

In order to capture the "lines before" you do not really have to go "back"; you can always keep the last "x lines read" and write them out when they preceed an occurance. You can maintain them in a small stack (ie. an array) and just push them from the top via AINS().

...

I use several source tools and editors ... some homegrown, some commercial.

With Norton TS (Text Search ... I'm using an old DOS version), I get a listing (piped to a file) of all the files that contain an occurance, the line numbers, and the lines before and after. The line numbers I rarely use since I'll call up the file(s) and do a Find (and Find Again) to go to the occurance(s). I mostly use TS to determine which files need looking at.

Visual Studio 6.0 is actually pretty handy for mass maintenance (as I suspect most "real" editors are). You can "Find in Files" (including *.prg), which gives a list with line numbers and statements; you can click on a line in the list which takes you to the line in that program; you can edit the program .... and even with inserts, the editor can still take you to the next occurance of the orignal find.

>Just as a side note, because of this program I hate the "Code Reference" program in VFP 8. Our program takes 2 minutes to run though the entire list while I have never had the enough time to wait for the "Code Reference" to finish.

Norton TS and VS 6.0 are pretty fast in handling "many" files ... particularly the second+ time around (OS buffering I imagine).

My VFP parsers are pretty good too though :)