🚀 go-pugleaf

"Lesley Anne" <mspfila-ng@yahoo.com> wrote in message
news:44f5ef4f@newsgroups.borland.com...

> > Why just just read inside the server's OnExecute event?
> > It is triggered on a per-connection basis.
>
> When is that triggered?

Immediately after the OnConnect event exits, OnExecute is triggered in a
continuous loop for the lifetime of the connection.

> It sounded from the help file as though it were triggered when
> a new thread is started

A new thread is created when a client connects to the server, yes.
OnConnect is triggered first, then OnExecute in a loop until the socket is
closed, and then OnDisconnect is triggered.

> which I assume would be only when a connection is first made.

You assume incorrectly.  That is not what the help file says.

> Is it triggered again after that?

Yes.  It is the main processing event for the thread.  It is triggered in a
continuous loop while the thread is running.

> the OnExecute event handler itself is in whichever thread the
> TIdTCPServer component is in (the main application thread if
> the server is on the form), rather than inside the individual thread
> that it references

It does not matter what class the OnExecute event handler is DECLARED in.
The OnExecute event handler (and any other event handler that provides
access to the connection's thread/context) is TRIGGERED in the context of
the worker thread that is managing the connection.  It is NOT triggered in
the context of the thread that owns the TIdTCPServer.

> how do you keep one connection from blocking all others

By being multi-threaded, TIdTCPServer already does exactly that for you.
Just read inside the OnExecute event, and only that one connection will be
blocked.  The other connections will trigger their own events separately.


Gambit