|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
StreamReader problems with BaseStream PositionI'm creating a class to read some text datafiles. These files start with a header with variable length, followed by a section with data values (numbers in separate lines) also with variable length. The data section must be read sequentialy, so my approch to this is: -Read the header (line by line) until find the header's end. -Store the Position of the BaseStream property of the StreamReader -Read the data section (also line by line) I need to store the stream position before start reading the data section, to be able to re-read the data without having to parse the header again. The problem is that the StreamReader buffers data, so the value returned in BaseStream.Position property is always ahead of the actual processed line. I understand that we need to call DiscardBufferedData after seeking in the base stream, so we start to read in the right position. But how can I know the exact position, discarding the buffered data that was not returned in the ReadLine method? Any other way to make this? Thanks! ferreira <ferre***@discussions.microsoft.com> wrote:
Show quote > I'm creating a class to read some text datafiles. I'm afraid you can't, as far as I know. If the file is encoded in a > > These files start with a header with variable length, followed by a section > with data values (numbers in separate lines) also with variable length. The > data section must be read sequentialy, so my approch to this is: > > -Read the header (line by line) until find the header's end. > -Store the Position of the BaseStream property of the StreamReader > -Read the data section (also line by line) > > I need to store the stream position before start reading the data section, > to be able to re-read the data without having to parse the header again. > > The problem is that the StreamReader buffers data, so the value returned in > BaseStream.Position property is always ahead of the actual processed line. > > I understand that we need to call DiscardBufferedData after seeking in the > base stream, so we start to read in the right position. > > But how can I know the exact position, discarding the buffered data that was > not returned in the ReadLine method? text encoding which is fixed-width, you could keep track of how much text has been read and multiply that by the width, but that's the only solution I know of :( -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Hi,
Thanks for your reply. The files are ASCII encoded, so the method you pointed works and is also very simple :) Thanks for the suggestion! Pedro Show quote "Jon Skeet [C# MVP]" wrote: > ferreira <ferre***@discussions.microsoft.com> wrote: > > I'm creating a class to read some text datafiles. > > > > These files start with a header with variable length, followed by a section > > with data values (numbers in separate lines) also with variable length. The > > data section must be read sequentialy, so my approch to this is: > > > > -Read the header (line by line) until find the header's end. > > -Store the Position of the BaseStream property of the StreamReader > > -Read the data section (also line by line) > > > > I need to store the stream position before start reading the data section, > > to be able to re-read the data without having to parse the header again. > > > > The problem is that the StreamReader buffers data, so the value returned in > > BaseStream.Position property is always ahead of the actual processed line. > > > > I understand that we need to call DiscardBufferedData after seeking in the > > base stream, so we start to read in the right position. > > > > But how can I know the exact position, discarding the buffered data that was > > not returned in the ReadLine method? > > I'm afraid you can't, as far as I know. If the file is encoded in a > text encoding which is fixed-width, you could keep track of how much > text has been read and multiply that by the width, but that's the only > solution I know of :( > > -- > Jon Skeet - <sk***@pobox.com> > http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet > If replying to the group, please do not mail me too > |
|||||||||||||||||||||||