thread appears to run after SetEvent

[divideby0]

I don't know if I've setup the thread correctly or not, but its behavoir isn't what I'd expect. I'm creating the thread within a BN_CLICKED message

typedef struct my_TNFO
{
    HANDLE h_event;
    HANDLE h_thread;
    DWORD  thread_id;
    BOOL   running;
    BOOL   init;
    BOOL   canceled;
} TNFO;

...
   if(HIWORD(wParam) == BN_CLICKED)
   {
       memset(&tnfo, 0, sizeof(tnfo));

       tnfo.running = TRUE;   // thread active
       tnfo.init = TRUE;      // thread started
       tnfo.canceled = FALSE; // user controlled 

       tnfo.h_event = CreateEvent(NULL, TRUE, FALSE, NULL);
       tnfo.h_thread = CreateThread(...);
       ...
    }
...

the thread function actually calls a recursive directory parser function. I've set it up as

DWORD WINAPI threads_ParseDisc(LPVOID lParam)
{
    TNFO *tmp = (TNFO *)lParam;

    if(tmp->init == TRUE)
    {
        tmp->init = FALSE;        
        // call recursive function        
    }

    while(WaitForSingleObject(tmp->h_event, INFINITE) != WAIT_OBJECT_0)
        Sleep(1000);

    CloseHandle(tmp->h_event);
    CloseHandle(tmp->h_thread);
    tmp->running = FALSE;

    return 0;
}

in the recursive function, I've tried both Send and PostMessage.

...
HANDLE hFind = INVALID_HANDLE_VALUE;

hFind = FindFirstFile(tmp, &wfd);

if(hFind == INVALID_HANDLE_VALUE)
{
    PostMessage(hwnd_to_main, WMU_DISC_DONE, 0, 0);
        return;
}

if(tmp->canceled == TRUE)
{
    PostMessage(hwnd_to_main, WMU_DISC_CANCEL, 0, 0);	   
        return;
}

do
{
   // if directory, call self... (path, tnfo);
   // if file, populate list view control

} while(FindNextFile(...) != 0);

FindClose(hFind);

++progd->count;
PostMessage(hwnd_to_main, WMU_DISC_COUNT, (WPARAM)0, (LPARAM)(ULONG)progd->count);

progd->count was devised to stop the thread when the recursion ended by posting a message to the main window. When it reaches 1, the def procedure sends the WMU_DISC_DONE message to set the event

All that *appears* to work; however, if I cancel the recursion thread, the list view continues to populate for a bit and then deletels all but 1 item though I send the message LVM_DELETEALLIT EMS.

If I move the (tmp->canceled == TRUE) test inside of the do-while, the app gets loopy. Any idea as to why this behavoir occurs?

If more information is needed, please ask.

TIA

[weaknessforcats]

OK. You have created an event object and a thread object and the thread is listening for an event. Where is the event?

I think you need to call SetEvent to put your event object into the signaled state. Otherwise, WaitForSingleOb ject will hear nothing.

[divideby0]

Thank you for the reply... as always, I appreciate your time and feedback.

The problem went away after moving the (tmp->canceled == TRUE) test to the bottom of the do-while. I still have no clue as to way the program bogged down if that test was at the top of the loop.

SetEvent was called within one of the WM_USER messages. The thread ended, but had a sort of delayed effect before. Moving the canceled test "fixed it."

Do you know of a way store the previously selected tab of a tab control? All I can get is the current selection, which isn't helpful for what I need to do.

TIA

[weaknessforcats]

I guess you would save the current tab in a stack. You could pop/push around the various tabs.

[divideby0]

I wish that I could learn to think like a programmer; thank you for that! Just what it needed. :)

Cheers