What I did was override DupConnected and call
TriggerSessionConnected() if the current state is
different than wsConnected:

Procedure TClientSocket.DupConnected;
  If (Self.State <> wsConnected) Then

  Inherited DupConnected;

    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.


>------- Original Message -------
>Sent    : 12/11/2007 4:10:31 PM
>To      : twsocket@elists.org
>Cc      : 
>Subject : RE: [twsocket] Simple TWSocket listener


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?


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

Reply via email to