🚀 go-pugleaf

"Kristoffer Persson" <no@email> wrote in message
news:401e070a@newsgroups.borland.com...

> This looks like a good idea, but my threads usually wait in
> a GetMessage call.

You can change your code to use PeekMessage() instead.  That will allow you
to check the message queue without blocking the thread so that you can then
performing timed waiting on the terminate event.

> Maybe a combination would be best, where I set an event
> and send a message to the threads.

No need for sending a message to terminate the threads, just set the event.
If you use MsgWaitForMultipleObjects(), it will tell you in a single
function call whether the terminate event was triggered or a new message was
received in the queue so that you can then call PeekMessage() to retreive
it.  For example:

    void __fastcall TMyThread::Execute()
    {
        MSG msg;
        HANDLE hTerminateEvent = CreateEvent(NULL, TRUE, FALSE,
"MyTerminateEvent");
        if( hTerminateEvent )
        {
            while( !Terminated )
            {
                switch( MsgWaitForMultipleObjects(1, &hTerminateEvent,
FALSE, 500, QS_POSTMESSAGE | QS_SENDMESSAGE) )
                {
                    case WAIT_OBJECT_0:
                        Terminate();
                        break;
                    case (WAIT_OBJECT_0+1):
                        PeekMessage(&msg, NULL, 0, 0, PM_REMOVE);
                        // handle message as needed...
                        break;
                }
            }

            CloseHandle(hTerminateEvent);
        }
    }


Gambit