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 : [email protected]
>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
