vb.net progressbar max value for number of lines in a file

Well there really is no such thing as 'lines' in the file, just a long string of characters (which may have newline characters).

If you are using a StreamReader, or similar, you can do StreamReader.basestream.length to see the total length.

Compare this to the Position property, and you can see the percentage of the file that has been read.

--KG

yeah right now I have a file that looks like this


100 students
just in time
5000


what I was trying to do is create a progress bar that moved as it read each line, but having the progressbar be set at 3 for the max. Now keep in mind the max may be 12 , 100, 300.

thats why I wanted to see if it could could lines,

Any better alternatives

Well it is not possible to know the number of lines in the file without reading the entire file first.  

But for small files like you have I dont know why you wouldn't read the entire thing anyway, it would happen instantaneously, so the progress bar wouldn't serve much purpose.

You can read the entire file, then do a split() on the newline character to get an array of lines......

But really no way to read the number of lines faster than reading the entire file, unless of course you write the number of lines to the top of the file, the first line could be '3' on  your example file.

well which is better.

dim lines as string
While filetoread.Peek <> -1
       lines = filetoread.readline
end while


or

dim i as integer
dim lines as string
dim linesplit () as string

lines = filetoread.readtoend
linesplit = line.split(vbcrlf)

for i = 0 to lines - 1
   msgbox linesplit(i)  
next


some textfiles will be really really big. Not sure what is better in memory, reading all at once or a line at a time.

where this is going if I readtoend then I can do a length and get how many lines, but I don't want to ruin performance if using peek is better

If your files will be "really really big" then reading the entire thing into a string and using split is not a good idea.  Reading line by line will take longer...but will not eat up lots of memory.

Your application could look for another file (say your text file is named "DATA.TXT" then this other file could be called "DATA.LEN" or something) and if it exists, read the number of lines from it before reading in the lines. If this extra file is missing or older than the data file (in case some other program changed it), then your application would count the number of lines as it reads the file, and then create a new line count file. Whenever the data file is written to, the line count file should be updated.

This would speed up operation in the long run. Some professional programs use similar methods, eg. CoolEdit, which is an audio editor that stores some complementary data in a "peak file" so loading is faster. If the peak file is removed or the .WAV file changed by another program then loading is slower the next time (and a new peak file is created).

If you prefer seeking and reading fragments from the data file to reading the whole thing into memory, then you might even want to store a complete index of all the lines in your complementary file (which in this case I'll call the "index file"). If you use a long integer for each line position then the length of the index file (if divided by 4, the size of a long integer) will be the number of lines, and to get the position of a specific line you'd first do a seek in the index file to the line number (starting at 0) times four to find out where the line is. As with the line count file described above, whenever the index file is missing or the dates of the index file and data file don't match, and whenever you change the data file, you'd have to rebuild the index.

Hope this is of some help to you.

so it the file.peek <> -1 a better way to read files???