ListView scroll pauses winsock

When I click on the scrollbar, winsock stops sending/receiving data until I release the mouse button.

Is this unavoidable?

Also happens with listbox and textbox. I guess it is unavoidable. :(

My question now is will this halt only the sends? Will the data arrivals still fire while I'm scrolling through the listview?

I'm doing a local connect so I have no way of testing this myself. Can someone pls help me.

hmmm... scrolling may block events from firing *while* you do it, but i dont think it would completely drop the events like they never occured. are you sure the events are not fired eventually after the scrolling operation is done?

Nope, I didn't mean to imply that winsock totally stops. It pauses until the mouse button is released whereupon everything resumes.

I'm just concerned how this may affect my program. What if the user goes tripping and decides to hold unto the scroll bar for a long period. What happens to the data arrivals? Are these placed in the call stack (or is it somewhere else?) or ignored? If stacked, will my program crash or something when the call stack is filled?

you would just have more data to process in a chunk. suppose the user falls asleep with the finger on the mouse button, and the amount of data received exceedes the internal buffer size, the machine will start NACK-ing the received packets until the buffer gets cleared by your app. as soon as theres some room in the buffer, the peer will start retransmitting the packets, and you would still receive them in the correct order. emm... of course, if everything is TCP.

Yet is TCP. Thanks for the input. BTW, is NACK "not acknowledged"?

Quote:

---

Originally posted by leinad31
BTW, is NACK "not acknowledged"?

---

Exactly.

the bottom line with tcp is 'dont worry'. ive seen a lot of people sending receipt confirmation messages back to the sender, to acknowledge a message, and going thru complicated procedures to test data integrity and stuff... but tcp does it all for them.