At 11:20 AM -0500 2/17/06, jon pipitone wrote:
Okay, so I'm left in a similar situation I was in before. How should I cope with the possibility of the Error event being called whilst I'm in the middle of handling some other socket event?
Well, to answer that, we'd first need to know why it's a problem. Why is it a problem?
But all of this seems like I'm really having to work around the (what I'd say is) faulty behaviour of the socket class. If the goal of having the Error event fire as a background task is so that my "code can realize that the socket is pretty much worthless at that point" then some rethinking needs to be done. Why? Because once the error event has completed the event it overlapped continues where it was interrupted and so doesn't "realize" anything.
Only if you've programmed it that way. If the other event needs to know when an error has occurred, then presumably you have some property you set in the error event, and check this in your other events.
I mean, if it's critical to realize the state of the socket we already have the tools with the LastErrorCode and IsConnected methods.
That's true too. So again, what exactly is the problem? Best, - Joe -- Joseph J. Strout [EMAIL PROTECTED] _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
