No. You are synchronizing *all* of TMyConnect's work back to the main thread, where it doesn't belong. You are defeating the purpose of using a worker thread. You need to get rid of the Synchronize(&TryMyConnect) call and just run the code directly in Execute() so it runs in the context of the worker thread. Use Synchronize() only when you need to run code that must run in the main thread, like accessing the UI.

Either way, I would suggest NOT placing the TIdTCPClient on the Form at all. Especially if you ever need to have multiple connections running in parallel. Move the TIdTCPClient into the thread instead, eg:

Your worker thread is using FreeOnTerminate=true, so its destructor runs in the context of the worker thread (after Execute() exits), not in the context of the main UI thread. To update your UI when the thread is finished, use the thread's OnTerminate event, which is synchronized with the main UI thread (before the thread object is freed):

ingalime wrote:And what do you recommend to write in catch TMyConnect::Execute?

Write whatever you want. Preferably, you shouldn't have the catch at all. That way, an uncaught exception will terminate the thread and populate the thread's FatalException property, which you can check to know if it terminated gracefully or abortively:

That is because your thread's Execute() method is catching and discarding all possible exceptions, so the FatalException property is never set. You need to get rid of the try/catch in your Execute() method. Or, catch exceptions but then throw your own exception with the desired Message assigned to it. Either way, you have to let an exception escape Execute() in order to use the FatalException property.

Last edited by rlebeau on Thu Jan 11, 2018 2:17 pm, edited 1 time in total.

You are basically just duplicating what OnTerminate+FatalException can already do. OnTerminate is synchronized with the main thread, and FatalException is set if Execute() exits due to an uncaught exception.

On Windows everything works as expected. In Android NO.In Android everything works as expected if server ON. If server OFF:segmentation fault 11 See all debug windows on picture.And catch does not work. Application crash if server OFF.

ingalime wrote:When the server OFF may need to add something to the properties TIdTCPClient if platform Android?

No, you do not.

The two exceptions you showed are perfectly normal. When the ConnectTimeout property is not 0 (the default), Connect() uses a worker thread to perform the actual connection. The thread terminates when the connection is established or an error occurs. Connect() waits up to the ConnectTimeout for the thread to terminate. If it does not terminate in time, Connect() closes the socket and terminates the thread.

The EIdSocketError exception you see is the actual connection failing. The EIdConnectTimeout exception you see is raised only if the thread did not terminate before the ConnectTimeout elapsed. Indy catches the EIdSocketError internally (which probably happens when Indy closes the socket, or just before), and EIdConnectTimeout is raised into your code for further handling as needed.

The debugger sees all exceptions before your code does. That is normal behavior. You can tell the debugger to ignore these Indy exceptions, or all Indy exceptions by ignoring EIdException.

These exceptions should not be causing a segfault, though. So something else is going on. You are going to have to debug further to find it.

Last edited by rlebeau on Thu Nov 30, 2017 12:02 pm, edited 1 time in total.