🚀 go-pugleaf

In article <40151062$1@newsgroups.borland.com>, Magnus Oskarsson wrote:
> I have a thread that spends most of its time waiting for various events
> and/or input in its message queue. Support for the latter was added so that
> it would be possible to create objects such as timers in code executed in
> this thread. It turns out that the thread receives a number of messages even
> when no objects such as timers are created, and that dispatching these
> messages occasionally causes an access violation. The messages in these
> cases were WM_DEVICECHANGE with wParam 7 and lParam 0. The key code looks
> like this:
> 
> PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE); {initialize the message queue}
> ....
> SignaledObject := MsgWaitForMultipleObjects(EventCount, HandleArray, False,
>   INFINITE, QS_ALLINPUT);
> case SignaledObject of
>   ...
>   {cases for various signaled synchronization objects}
>   ...
>   else {input in the message queue}
>     while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
>       DispatchMessage(Msg);
> end;
> 
> What is it that is wrong with this code? 

You may want to check Msg.Hwnd and only call DispatchMessage if the window 
handle is > 0. That should be safe enough. But there is actually no point in 
using timers inside a secondary thread, just use a appropriate timeout on the 
wait...


--
Peter Below (TeamB)  
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be