Hello: What I did was override DupConnected and call TriggerSessionConnected() if the current state is different than wsConnected:
Procedure TClientSocket.DupConnected; Begin If (Self.State <> wsConnected) Then Self.TriggerSessionConnected(0); Inherited DupConnected; End; This seems to work and I don't see why it would be a problem. Can anybody tell if this is a bad idea? I also can't think why the component wouldn't do this itself. That way, if you assign the socket to a client object, you can still take care of it as you would a normal TWSocket client object using OnClientConnected and OnClientDisconnected to mark the lifetime of the connection. -dZ. >------- Original Message ------- >From : [EMAIL PROTECTED]:[EMAIL PROTECTED] >Sent : 12/11/2007 4:10:31 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] Simple TWSocket listener question > <!SNIP!> I've noticed that when this is done, the OnSessionConnected event of the client is never triggered. I thought this was unusual as I thought that FD_CONNECT (which ultimately triggers the event) comes after FD_ACCEPT. Or am I doing something wrong? -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be