ingalime wrote: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.
I know for a fact that Indy works on Android. You are just going to have to debug the code to find the root culprit.
ingalime wrote:And catch does not work.
You shouldn't be using catch(...) to begin with. Even on Windows, it is not guaranteed to handle Delphi-style exceptions correctly. Catch exceptions by type explicitly, eg: catch(const Exception&).
Even better, just get rid of the try/catch altogether, and let the exception terminate the thread and set its FatalException property.
Also, you can get rid of the try/__finally by using a smart pointer like std::unique_ptr.
- Code: Select all
#include <memory>
void __fastcall TMyConnect::Execute()
{
std::unique_ptr<TIdTCPClient> Client(new TIdTCPClient);
Client->Host = FHost;
Client->Port = FPort;
Client->ConnectTimeout = 5000;
Client->Connect();
Client->IOHandler->Write(FLines, true, IndyTextEncoding_UTF8());
Client->Disconnect();
}
...
MyConnect = new TMyConnect(...);
MyConnect->OnTerminate = &ThreadTerminated;
MyConnect->Start();
...
void __fastcall TFormMenu::ThreadTerminated(TObject *Sender)
{
TMyConnect *Thread = static_cast<TMyConnect>(Sender);
...
if (Thread->FatalException)
ShowMessage(static_cast<Exception*>(Thread->FatalException)->Message);
...
}
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.