🚀 go-pugleaf

"enzo" <enzo.arlati@aesys.it> wrote in message
news:43901442$1@newsgroups.borland.com...

> Application->ProcessMessages() used inside a thread should
> not be a good idea, but for now is working.

You are right that it is not a good idea.  ProcessMessages() is not designed
to be called from outside of the main thread.  It is not a thread-safe
method.  DO NOT call ProcessMessages() from the context of a worker thread.
If you must use a non-blocking socket in a thread, then you should write
your own message queue manually by calling PeekMessage(), TranslateMessage()
and DispatchMessage() instead of ProcessMessages(), ie:

    clientSck = new TClientSocket( NULL );
    clientSck->ClientType = ctNonBlocking;
    clientSck->Address = ipTargetFep;
    clientSck->Port = portTargetFep;
    clientSck->Open();

    MSG msg;
    for(int idx = 0; (idx < 100) && (!clientSck->Active); ++idx)
    {
        if( PeekMessage(&msg, NULL, 0, 0, PM_REMOVE) )
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
        Sleep(10);
    }

    if( !clientSck->Active )
    {
        //...
    }


>           clientSck->Close();
>           clientSck->ClientType = ctBlocking;
>           clientSck->Open();

Why are you closing the socket immediately after opening it?  You should not
be doing that.  There is no guarantee that the second Open() will succeed,
so you'll be right back to square one again.

If you really want to use a blocking socket in a thread with a connect
timeout, then I suggest not using TClientSocket in the first place.  Use
Indy (http://www.indyproject.org) instead.  It uses blocking sockets for
everything and is designed to be used with threading.  Its TIdTCPClient
component has a connect timeout available.


Gambit