StreamWriter not "bidirectional"?

[treddie]

From what I have been experimenting with, it seems that StreamWriter is not "bidirectional" in that you cannot write to and read from a file using the same port. It seems that in order to read from the file you have to close the StreamWriter and then open a new StreamReader. Is this correct? If so, what a pain, if you want to write and read Unicode characters without having to close and open ports every 2 seconds.

[formlesstree4]

Why are you wanting to do that anyway? What OS can you actually do that in anyway?

[jmcilhinney]

As the name suggests, a StreamWriter is for writing and a StreamReader is for reading. As the names also suggest, they are for writing to and reading from Streams. They are not specific to files, although FileStreams are the most common Stream they write to and read from. They can work with any type of Stream though, e.g. GZipStream for compression and decompression, CryptoStream for encryption and decryption and NetworkStream for network communication. A Stream is basically something through which binary data can flow.

A StreamWriter accepts text, converts it to binary data and writes it to the underlying Stream, while a StreamReader reads binary data from a Stream and converts it to text before returning it. A FileStream is what actually interacts with a file when reading and writing. You can create a FileStream that is configured to both read and write and then pass it to the constructors for a new StreamWriter and StreamReader. You can now write to and read from the same file without having to open and close anything.

Just be aware that it is the FileStream that keeps track of where data is to be written to and read from, e.g. if you read data with the StreamReader and then write using the StreamWriter, the new data will be written immediately after the data you just read. As such, you may need to use the Position property or Seek method at times to ensure that you're pointing to the correct location in the file.

[formlesstree4]

As the name suggests, a StreamWriter is for writing and a StreamReader is for reading. As the names also suggest, they are for writing to and reading from Streams. They are not specific to files, although FileStreams are the most common Stream they write to and read from. They can work with any type of Stream though, e.g. GZipStream for compression and decompression, CryptoStream for encryption and decryption and NetworkStream for network communication. A Stream is basically something through which binary data can flow.

A StreamWriter accepts text, converts it to binary data and writes it to the underlying Stream, while a StreamReader reads binary data from a Stream and converts it to text before returning it. A FileStream is what actually interacts with a file when reading and writing. You can create a FileStream that is configured to both read and write and then pass it to the constructors for a new StreamWriter and StreamReader. You can now write to and read from the same file without having to open and close anything.

Just be aware that it is the FileStream that keeps track of where data is to be written to and read from, e.g. if you read data with the StreamReader and then write using the StreamWriter, the new data will be written immediately after the data you just read. As such, you may need to use the Position property or Seek method at times to ensure that you're pointing to the correct location in the file.

I forgot that a FileStream has read/write properties...man it's been a long day. Thanks for that refresher.

[jmcilhinney]

I forgot that a FileStream has read/write properties...man it's been a long day. Thanks for that refresher.

I know how that goes. Posted a dodgy one myself this morning after 5 hours sleep. tg rescued me with the correct answer though. Backup is always good.

[treddie]

Heheh. Age makes it worse.

Ok then, I understand. I wasn't aware of FileStream yet, just StreamWriter and StreamReader as separate entities.
Thanks everybody.

p.s. I must confess I was brain-farting myself, thinking that (while not supporting Unicode), FilePut and FileGet could work together without first opening a file as Input or Output, first.

[jmcilhinney]

Ok then, I understand. I wasn't aware of FileStream yet, just StreamWriter and StreamReader as separate entities.

When you create a StreamWriter or StreamReader by passing a file path to the constructor, it simply creates a FileStream itself, but configures it for one-way data flow.

[treddie]

Then it sounds like a FileStream can be either in control of or subordinate to a writer and reader. A Writer or Reader assigns a FileStream, but a FileStream can assign StreamWriter/StreamReader properties.

[jmcilhinney]

Then it sounds like a FileStream can be either in control of or subordinate to a writer and reader. A Writer or Reader assigns a FileStream, but a FileStream can assign StreamWriter/StreamReader properties.

No. A FileStream just is. You can create a FileStream in your own code or a StreamReader/StreamWriter can create one in its code but either way a FileStream is a FileStream and it does what it does. Whether you pass a FileStream that you created yourself when creating a StreamReader/StreamWriter or you just pass a file path and let the StreamReader/StreamWriter create the FileStream itself, that FileStream is accessible via the BaseStream property of the StreamReader/StreamWriter. The only difference is that, if the StreamReader/StreamWriter opened the FileStream, it will also close it when it is disposed. The FileStream itself is exactly the same regardless and has no knowledge of where it was created.

[treddie]

Got it. Makes sense. Funny how this all came about. Asking about a capability based on an incorrect assumption about something I already knew about but forgot and ended up learning something new about FileStreams.