In the first post sBuffer was a single Static String that was serving for all connections. This flaw was made much worse by the use of DoEvents() in the DataArrival event handler of course, but was a problem nonetheless.

The sample code in the ZIP archive I posted corrects this without changing the "style" of the program's buffer handling too much. It uses a String array of buffers, one per connection.

Do people realize what DoEvents() really does? I wonder. If so they'd be loathe to ever use it in Winsock control programs. A lot of programmers are already in a trance trying to cope with concurrency without adding this Joker to the deck. I suspect its presence is often a desperation measure when nothing else seems to work.

There are places for DoEvents(), but this just isn't one of them. Here it allows DataArrival for Connection 3 to be interrupted by DataArrival for Connection 7 (or whatever), and on and on, jamming everyone's input into the same sBuffer, etc. It can also lead to a stack overflow if you have several connections or a lot of data arriving. DoEvents() isn't a pause (or much of one). It simply calls the Form's Windows Message Loop once and then gives up its processor slice, like doing a Sleep(0) call, and then returns the oprn Forms count (which most people discard, calling it as if it were a Sub instead of a Function).


If studying the sample didn't help enough perhaps this explanation will shed a little more light.