Quote:By default, TClientSocket operates in non-blocking mode (TClientSocket::ClientType = ctNonBlocking). In that mode, the client uses an HWND window internally to handle socket events. It also means that the client connects to its server asynchronously, delivering a completion event to its HWND once the connection is successful or fails.

An HWND window has thread affinity, meaning it can only operate within the thread that creates it, and that thread must have a message loop to process and dispatch any messages that are sent to that window.

The TButton events are being fired in the main UI thread, and thus use the main UI message loop for processing. If the TClientSocket creates its HWND in the main UI thread, then everything is handled for you.

However, the TIdTCPServer events are fired in separate worker threads, one for each client that connects to it, and those threads do not have messages loops by default. So, you can't use TClientSocket in non-blocking mode inside of a TIdTCPServer thread without some extra work. Specifically, you must either:

• give each TIdTCPServer client thread a message-dispatching loop, ie in the server's OnExecute event.
  
• otherwise, put the TClientSocket into blocking mode (TClientSocket::ClientType = ctBlocking) instead, in which case no HWND is used at all, and the client connects to its server synchronously. However, you will then have to use a TWinSocketStream object to handle all reads/writes on that TClientSocket after its connection is successful.
  

(03-21-2023, 02:59 AM)Max2009 Wrote: Yes, the connection worked. The TClientSocket component has a good OnRead property, which means that I can connect to the server and have a constant connection. Data comes from the server and I can read it immediately without reconnecting. Is there a similar possibility in TIdTCPClient? The component has an OnConnect property, but it only triggers once. It is unclear how to receive data without reconnecting.

• have a worker thread read from the TIdTCPClient.IOHandler in a blocking manner, and then delegate received data where needed.
  
• or else, have the main thread use a UI timer or sleep loop to periodically poll the TIdTCPClient.IOHandler for new data using a short timeout, and then use any received data as needed.
  

• if your server code is preventing TIdTCPServer from recognizing the disconnect so it can tell the appropriate thread to stop running.  For instance, if your TIdTCPServer.OnExecute event handler swallows Indy exceptions from bubbling up the call stack.  Remember, Indy uses exceptions to report errors, which includes when a peer disconnects while a blocking socket operation is in progress.  If TIdCPServer catches an exception raised from its events, it will shut down the raising thread. So, if you are catching exceptions in your own code, make sure you re-raise any exception that is derived from EIdException, at least.
  
• if the disconnect is abnormal in such a way that the OS has not detected it yet, then it will not have been reported to Indy yet.  Eventually, the OS will timeout internally and report errors on a lost connection, but that timeout is quite large, so it may take awhile.  You can use timeouts in your own code to help avoid that.  Either with Indy's own ReadTimeout properties and function parameters, or by enabling TCP keep-alives on the connection.