locked
StreamReder: Read does not work, Peek lies to me :-( RRS feed

  • Question

  • Hi guys!
    I'm having a lot of trouble with the StreamReader in C# on my PocketPC.
    The stream reader is receiving data from a serial connection. Now I want to get this data and display it in a textbox. But this ain't as easy as it seems. I've tried different possibilities but none works. Here they are:

    1) Using StreamReader.Read in a timer's code:

    Code Block

    private void timer1_Tick(object sender, EventArgs e)
    {

    textIn.Text += (char)sr.Read();

    }


    This works fine except for one problem: When there is nothing to read the Read Method waits for new input. This stops the whole application! So no controls can be pressed etc.

    2) My first idea to solve this problem was to do this code in a seperate thread. So that it would not stop the rest of the application while it is waiting. But Threads seem not to be supported in WindowsMobile???

    3) The I used the peek method to avoid calling Read if there is no input. Like this:

    Code Block

    private void timer1_Tick(object sender, EventArgs e)
    {

    while( sr.Peek() >= 0 )
    {
    textIn.Text += (char)sr.Read();
    }

    }


    This works only in the beginning, where there are some letters in the pipeline. Once they've been written Peek() always return -1 EVEN IF NEW DATA HAS ARRIVED! So no more letters are written to text box....

    Why is that so difficult? How can I read bytes from the StreamReader without stopping my whole program?

    Thanks for your help!

    Thursday, December 13, 2007 12:40 PM

Answers

  • How about this:

     

    Code Block

    private void timer1_Tick(object sender, EventArgs e)
    {

    while( port.BytesToRead > 0 )
    {
        textIn.Text += port.ReadExisting();
    }

    }

     

     

    Threads are supported by NETCF and so are asynchronous receive events. That, however, would trigger need to marshal these on to UI thread.

    Thursday, December 13, 2007 6:23 PM

All replies

  • How about this:

     

    Code Block

    private void timer1_Tick(object sender, EventArgs e)
    {

    while( port.BytesToRead > 0 )
    {
        textIn.Text += port.ReadExisting();
    }

    }

     

     

    Threads are supported by NETCF and so are asynchronous receive events. That, however, would trigger need to marshal these on to UI thread.

    Thursday, December 13, 2007 6:23 PM
  • The StreamReader class doesn't have any BytesToRead or ReadExisting members/methods...or am I missing something?
    Thursday, December 13, 2007 7:48 PM
  • hi

     

    the problem is outside the shown code. how does stream object get data???

    Thursday, December 13, 2007 11:53 PM
  • I'm using the InTheHand Bluetooth library. This creates a stream reader and writer object for me. So there's not much I can do about it....
    Friday, December 14, 2007 9:24 AM
  • Variable 'port' is not a stream but serial port you're reading from. I've assumed that's what you meant by "serial connection".

    If stream of unknown nature is provided to you by 3rd party code then you should consult that 3rd party about correct handing of the stream.

    Friday, December 14, 2007 6:54 PM
  • I completely agree, this is completely unreal that this doesn't work.  Having done stuff in qt recently the sockets are beautiful there comparitively.  It is starting to look like I'll need to drop down to the sockets layer and do all the work there that should just be usable with the nicely built (in theory) streams.

    I'd argue that you shouldn't even need to use peek/read, but that the

    result = await srReadLineAsync() with a timeout set should be all that is needed to have a non blocking socket read.  I'll save you the time though and let you know that the day or so I've spent trying to make this functional was completely fruitless, and then to have the fallback to peek()/read() fail also because peek isn't trustworthy is almost unbelievable for such a mature product.  Maybe it works in C++ but not c#, but I can't see that not being part of the .net library issue, which I'm starting to think is very inappropriately named if it can't make this simple socket stuff nearly transparent.  <end rant>

    If anyone knows if I'm just making a new persons mistake that would be great, but for the amount of searching I've done I can assure ms that I am FAR from alone in this problem.

    Saturday, September 20, 2014 2:50 PM