Hello Mitchell,
Yes there should be a Connect (or Listen) before sending something. UDP
is not session related but it is the way TWSocket is written. But for
UDP you dont have to wait for an event, you can call Connect and in next
line of code you can call SendStr. Also it is OK to Release the TWS
Lost handles using TWSocket.
Hello Mitchell,
> Does it seem reasonable that the Release call in Disconnect should be
> changed to a Close or CloseDelayed, and the Release in SessionClosed
> remain?
If you wants to destroy from within an event handler then call Release.
Yes it indeed post
Hello Mitchell,
> Does it seem reasonable that the Release call in Disconnect should be
> changed to a Close or CloseDelayed, and the Release in SessionClosed
> remain?
If you wants to destroy from within an event handler then call Release.
Yes it indeed post a message to destroy it outside the e
ubject: Re: [twsocket] Lost handles using TWSocket.
Hello Mitchell,
Never have seen this problem, but I'm not fully understeand. You talk
about rapid open / close, but you use UDP (wich is not session related)?
Can you explain this again, maybe I have misunderstood.
---
Rgds, Wilfried
Hello Mitchell,
Never have seen this problem, but I'm not fully understeand. You talk
about rapid open / close, but you use UDP (wich is not session related)?
Can you explain this again, maybe I have misunderstood.
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http
To All,
I have inherited an application that uses UDP to communicate between a
DLL (previously 16-bit) and a 32-bit EXE. A long time ago we saw a
problem with Windows 98 where the fairly rapid opening and closing of
sockets resulted in lost handles. This appeared to be a defect in the
Winsock un
