🚀 go-pugleaf

Thank You very much Mr. Lebeau!!

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:41fe99bf$1@newsgroups.borland.com...

>> From the BCB Help I read: "The thread for each connection generates
>> OnClientRead or OnClientWrite events when the server socket needs
>> to read or write."
>
> That is only true if you do not write your own thread class.  The default
> TServerClientThread.ClientExecute() implementation triggers the events. 
> By
> overriding ClientExecute() with your own implementation, you lose those
> events unless you trigger them manually, which you usually don't need to 
> do
> if you are implementing ClientExecute() yourself anyway.
>

Thank You now it takes a clear shape in my mind!:)

>> I should use the OnClientWrite when I need to write to the clients.
>
> That is not correct.  Just like with non-blocking mode, OnClientWrite is
> only used to indicate that a socket has become writable, not that you 
> should
> be doing all of your writing from there.
>

Great!! Thanks!! Now finally I understand what that event is needed for!:)


> I never said to use ProcessMessages() from a thread.  I did say, however,
> that non-blocking code could be written in a similar fashion to blocking
> code, as long as you taking blocking situations into account properly.
>

Sorry my english was not clear, with thread I meant a newsgroup thread... 
You wrote
>The easily way is to simply call Application->ProcessMessages() inside your
>loop whenever SendBuf() returns -1 so that OnWrite can be processed.
in "Re: Client: ctNonBlocking -> Server: stThreadBlocking" newsgroup thread

>> But my confusion starts from how they work and when I should
>> use a "stThreadBlocking" instead of "stNonBlocking" server.
>
> That is entirely up to you and your actual needs.

My needs are that the server can send or receive those big files at the same 
time without one client sitting while waiting for others!

> Because it is not blocking.  "Blocking" vs. "non-blocking" refers to the
> socket itself, not the server component managing the socket.  In blocking
> mode, socket operations "block" the calling code until the socket 
> operation
> is finished.
Sorry but I still don't understand :( What do You mean with calling code? 
the process main thread? But if each socket connection gets its own thread 
how can it block the main thread?

> In "non-blocking" mode, socket operations return control to
> the calling code as soon as possible and then trigger asynchronous events
> when the operations actually finish.

that is the OnClientRead is triggered once the socket has finished to 
receive, Do I mistake? If so the block with "non-blocking" server is only 
due on how I take to parse the arrived packets ...

>> Why should I use the threaded way for a TClientSocket?
>
> Easier coding of the socket operations (your code does not have to be
> separated amongst multiple event handlers), simultaneous processing of
> multiple clients at a time, etc.
>
I always thought that one of the most important features of BCB vs VC was 
the clearness due to the events handlers ...


P.S. to Mr Gambit, You never answered a my problem about redirecting std 
I/O, even if I think U know how to manage that, but I want tell You that I 
actually solved that problem... I needed to Grant Session SID Access To the 
current user's  Winstation And Desktop to my process in order to get the 
consolle redirected fine. A very advanced stuff for me, and of course I 
could accomplish that only by reusing a code snipped from the net:-)