You should only treat the status events as UI level notifications.
They aren't meant to be programmatically used to switch state.
You can use nsIInputStream::Available to test if the stream is closed.
(If it returns NS_BASE_STREAM_WOULD_BLOCK, then just treat that as
meaning that the stream is not closed yet.)
By the way, when reading from a socket input stream, you are most
likely reading from a pipe input stream instead.
-Darin
On 3/4/06, Jon Smirl <[EMAIL PROTECTED]> wrote:
> I'm still trying to figure out how to tell that the socket has been
> closed. I was going to use OnTransportEventSink but now I see that it
> doesn't have a close event. Seems like it should.
>
> /**
> * nsITransportEventSink status codes.
> *
> * Although these look like XPCOM error codes and are passed in an
> nsresult
> * variable, they are *not* error codes. Note that while they *do*
> overlap
> * with existing error codes in Necko, these status codes are confined
> * within a very limited context where no error codes may appear, so there
> * is no ambiguity.
> *
> * The values of these status codes must never change.
> *
> * The status codes appear in near-chronological order (not in numeric
> * order). STATUS_RESOLVING may be skipped if the host does not need to
> be
> * resolved. STATUS_WAITING_FOR is an optional status code, which the
> impl
> * of this interface may choose not to generate.
> */
> enum { STATUS_RESOLVING = 2152398851U };
> enum { STATUS_CONNECTING_TO = 2152398855U };
> enum { STATUS_CONNECTED_TO = 2152398852U };
> enum { STATUS_SENDING_TO = 2152398853U };
> enum { STATUS_WAITING_FOR = 2152398858U };
> enum { STATUS_RECEIVING_FROM = 2152398854U };
>
> --
> Jon Smirl
> [EMAIL PROTECTED]
> _______________________________________________
> dev-tech-network mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-network
>
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
