I've been working on a problem that the new IDE beta tester brought to my attention.
He used the Find-in-File feature in a different manner than I alway use it (that's why you have beta testers) and he made it crash the IDE.
After a little playing arounf I could make it crash (which is helpful when you are trying to debug.
My routine works internally this way.
You pass it a starting path and text to find.
The 1st thing I do is do a recursive dir and file search and put the results in a linked list.
So, that puts all the files I need to look in in the list.
Then, I start going through the lisst one file at a time.
I have an internal list of file extensions that I automatically skip (exe, dll,lib,all images, mdb,dbf, etc)
With the worst case scenario(seaching the entire C drive) all the remaining file names take up a few hundred K of memory.
As I take each remaing file I send it to a sub where I try to determine if is what I consider a valid text file.
I have to do that because file extensions can be changed by the user and even create there own.
The other is the fact that there is no magic flag to determine if any given file is a valid text file.
Because there are some things that can be checked for I load the file in memory.
I then look at each character and make some test.
First I check a character to see if it is a chr$(0). If it is I throw the file away and get another one.
The next thing I do is check to see if is a valid printable ASCII char (Chrs(9),Chrs(13),Chrs(10),(>Chrs(31) and <Chrs(127))
The problem there is that a 20K html file can meet that criteria and and not have a CRLF which is needed in the actual searching subroutine.
If the buffer isn't large enough it will cause a crash.
So I count each char as I test it. When I hit a Chrs(10) I set a flag to look for the Chrs(13).
I compare the current character count to a max count and set the max to the larger of the two.
That way I'm identfying the longest line I have to input. If it gets too big I toss the file.
I had to do this because of the above and the fact that *.js files and html files can have a mix of lines that end in CRLF
and then a block of 1000's of chars with no CRLF.
I thought I had it resolved until I ran into a file that passed my testing code and then crashed because of a block of spaces on the tail end of the file..
So, I've been fighting this for two days now.
One alternative is keep the User from being able to search the C drive(or any drive) from the root down. That would solve sove memory and time issues.
Also, to restrict the User to only searching for certain file extensions, which I really hate to do.
And even that doesn't totally solve the issues because the User can change file extensions.
I'm open to suggestions.
And the challange is for one of you to code a scheme that does the above and is bullet proof as possible.
I'm at the point I'm going to have to drop it for a while to let my head clear.
I'm missing something. You are asking us for code to solve a problem for a version
of IWBasic that is being beta tested (that we do not have).
Bill
Forget that it has anything to do with the new IDE at all (I scratched the references to the new IDE in my original post.)
I described a subroutine I'm trying to write and what it needed to do.
I was just asking for someone else to write a subroutine that would accomplish thye same task.
My thought was that someone else would do it a little differently and that would give me an idea of how to make mine bullet proof.
I reckon it was a bad idea. :-\
I'll just keep plugging away and whatever I come up with that I'm comfortable with will be what the user's of the new IDE will get.
No, no. My misunderstanding. I'm sure someone can help. I'm not good
enought yet.
BTW. Why not (>Chrs(32))?
Good Luck,
Bill
Got it resolved!
Cancel the challenge.
I let it run for a few hours(it processed over 800,000 files and it was doing what I wanted it to.
I'm am going to have to add a progress/busy indicator so the user knows it is working at all times though.