Recently I saw a question about DoEvents and someone had mentioned doing it in a thread. I have been trying to figure out if it's possible. When you use PeekMessage it will only "see" messages from the current thread so if you try to do it in a thread it will not see the messages and essentially just does nothing. I tried to use AttachThreadInput but that really isn't the message queue so it doesn't work either. Is there a way to "see" the messages in another thread besides a message hook ?

Called as follows :

invoke CreateMutex,NULL,TRUE,"ThreadSyncMutex"

mov [hMutex],eax
invoke GetCurrentThreadId
invoke CreateThread,NULL,NULL,OFFSET DoEventsProc,eax,NULL,ADDR DoEventsID
invoke CloseHandle,eax
DoEventsProc FRAME lParam ; LParam = Thread ID of main thread


; Force a message queue to be created by making a GDI call
invoke GetDC,NULL
invoke ReleaseDC,NULL,eax

invoke GetCurrentThreadId
invoke AttachThreadInput,eax,[lParam],TRUE

or eax,eax
invoke TranslateMessage,OFFSET msg
invoke DispatchMessage,OFFSET msg

invoke WaitForSingleObject,[hMutex],1000
cmp eax,WAIT_OBJECT_0

invoke GetCurrentThreadId
invoke AttachThreadInput,eax,[lParam],FALSE
invoke ExitThread,0

The Mutex is freed when I want the thread to exit.
Posted on 2004-02-24 22:40:26 by donkey

Pretty much decided it's not possible without trickery. I think I'll stick to letting my message loop run and doing the other stuff in the thread.
Posted on 2004-02-24 23:12:27 by donkey
Perhaps you could do the GetMessage in your main thread, but send off Translate+DispatchMessage to the other thread - can't really see anything but disadvantages doing it this way, though :)

Are there any disadvantages for you by doing message processing in your main thread, and offloading work to a worker thread?
Posted on 2004-02-25 00:42:43 by f0dder
No, I was just curious because I always thought it was not possible. But someone had mentioned it as a possiblity so I thought I would try to see if there was an easy way to do it. My only current project that uses multithreading already offloads the intensive work to the thread and continues the loop. The only real advantage would be that I could signal the loop and do a clean exit in case of a cancel. It is a much more complicated affair with the intensive part in the thread because I would have to set up way-points to listen for a cancel in the thread, inside a message loop I just wait for the object to become signalled. I could avoid the TerminateThread if the message processing were in the thread.
Posted on 2004-02-25 03:51:42 by donkey
Always nice to play around with stuff :P

As for signalling... it's very easy to terminate the messageloop from a worker thread, but it indeed requires some annoying logic to terminate worker threads (cleanly) - like checking for an event object every X iterations or similar :/
Posted on 2004-02-25 10:08:31 by f0dder