Edward wrote: > Not 100% sure, but I thought that your loop will not work if > the message on top of the queue is not falling into your > range, and the message would remain on the queue (due to > 'NOREMOVE' flag), and will be peeked everytime afterwards. > > Not sure which message MadExcept uses, it could well be > outside of your message ID range.
Yeah, I think Edward is likely spot on here. Whatever message this code is preventing from being dispatched (i.e. the one that previously was causing an error when Application.ProcessMessages was called instead) is sitting at the top of the message queue and since it's not being dispatched, it will keep being returned from PeekMessage and no other windows messages will be being dispatched. Windows detects hung applications on the basis of apps failing to process WM_PAINT messages for a period of time. Now, technically, WM_PAINT messages are not actually _sent_, they are synthesized based on your applications dirty regions but only when the message queue is otherwise empty but the principle is the same. If you're blocked from processing any messages, you're blocked from processing WM_PAINT. You might be able to force WM_PAINT calls to be pumped by clever use of PeekMessage with the PM_QS_PAINT flag to dispacth only WM_PAINT messages but I've never tried that. We've modified Forms.pas to allow conditional PM_QS_ family flags to be passed to Application.ProcessMessages to control the potential re-entrancy issues that ProcessMessages entails. Being able to process all outstanding messages without dispatching input is generally far safer. Anyway, without knowing more context, I'd be inclined to reinstate the Application.ProcessMessages and attempt to figure out what the offending messages that was causing the original problem rather than futzing with the message loop. The Windows message loop is subtle and prone to anger :-) It also behaves differently under Windows 7 so we had to tweak our conditional dispatch code to avoid spurious 'hung application' issues that Windows XP and Vista were fine with. Essentially, if Windows 7 doesn't see an unconditional PeekMessage being called regularly, it also consider the app to have hung, even though you are conditionally pumping WM_PAINT and other messages. A single unconditional PeekMessage PM_NOREMOVE will satisfy it. Go figure as to why MS changed this. Cheers, Paul. _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
