I had a very wired problem and don't know if my solution is right:

I have a main program that:
- opens a list view control
- start a filling thread
- wait for thread end

the filling thread does:
- clear list (LVM_DELETEALLITEMS)
- insert new items (LVM_INSERTITEM)
- exit if done

the effect: if I wait in the main thread with WaitForSingleObject (hThread) the main program AND the thread are blocked.
After trying a lot of things, I found out, that the SendMessages from the thread need some feedback from the main
program, which waits. So also the thread does not continue.

I found a solution at Microsoft, they recommend an own message loop with PeekMessage and MsgWaitForMultipleObjects.
Is this a standard way? I also tried PostMessage instead of SendMessage, but this leads to a crash in comctl32.dll
Posted on 2003-01-02 04:51:18 by beaster
Yes, you have to do that. Or, you could post a message from the other thread when it is done.
Posted on 2003-01-02 06:15:51 by Sephiroth3
Windows:DEVELOPER issue March 2002 under Tech Tips has a article that details the use of this method. You will need to transcribe it from C, but it's short and sweet and should not be difficult.

Enjoy your work, P1
Posted on 2003-01-02 08:42:07 by Pone
Why not just let the main program running (don't block) and send a custom message to it from the thread when it's done? A thread is no use if you wait for it to complete (isn't really multithreading, is it :) ).

I also tried PostMessage instead of SendMessage, but this leads to a crash in comctl32.dll

Did you by any chance pass pointers as wParam or lParam to PostMessage? IIRC, as PostMessage doesn't wait for the message to be handled it may be handled later, when your pointers have gone invalid. But if you use the above method you can just use SendMessage, it will return fast because nothing is blocking.

Thomas
Posted on 2003-01-02 14:57:57 by Thomas
in normal case I do not wait for thread.
The list shows a directory and if the user decides to choose a different path, the filling should
stop immediately and the new path should be displayed. So I set an event to tell the thread to stop,
then I wait for the thread to come to and end, and then I start the thread again with the new path.
Did you by any chance pass pointers as wParam or lParam to PostMessage
yep - that was the problem with
the PostMessage.

My final solution looks now like this (Microsoft to asm translated):
WaitMessageLoop	PROC	USES edi, hevEvent:DWORD


sub esp, sizeof MSG
mov edi, esp

wmlLoop: xor eax, eax
push PM_REMOVE
push eax
push eax
push eax
push edi
call PeekMessage
test eax, eax
jz wmlWait

push edi
call DispatchMessage

jmp wmlLoop

wmlWait: lea ecx, hevEvent

push QS_ALLINPUT
push INFINITE
push FALSE
push ecx
push 1
call MsgWaitForMultipleObjects
cmp eax, WAIT_OBJECT_0
jne wmlLoop

wmlExit: add esp, sizeof MSG
ret

WaitMessageLoop ENDP
Posted on 2003-01-03 10:46:38 by beaster