Win32 message timeout clears my window

1
votes

Take the simplest possible Windows program with a window and message loop, such as a Hello, World program.

Suppose that just before I enter the message loop, I draw into the window (naughtily done outside processing of wm_paint, but bear with me).

If I spend more than about 5 seconds doing this, or I draw something then spend 5 seconds doing something else, before I start the message loop, then the message system seems to 'time out'. The MSDN docs for PeekMessage says it becomes 'unresponsive' and turns it into a 'ghost' window.

My problem however is that it also clears the contents of the window!

Is there way of stopping it doing that? The same 'unresponsive' caption is shown if I spend too long drawing into the window even during offical wm_paint processing; it also starts to behave oddly by generating more wm_paint messages.

It seems very restrictive if everything (eg. complicated rendering, or image processing) must be done within 5 seconds, or if any algorithm needs to keep prodding the message queue to stop it timing out!

2
winapiwin32gui
If you want a responsive UI you need to respond to messages in a timely manner. I don't see much of a restriction outside of logical necessities. Your observations with respect to WM_PAINT messages is also incorrect: There will not ever be more than one WM_PAINT message in the message queue. In fact, there isn't even a single WM_PAINT message in the queue; it is generated by a message retrieval function, if the invalid area is non-empty, and there aren't any higher priority messages in the message queue. – IInspectable
The ghosting feature is described on MSDN: Preventing Hangs in Windows Applications. It can be disabled with DisableProcessWindowsGhosting() – Remy Lebeau

2 Answers

0
votes

This is by design. You must keep checking for messages so that you can respond to user events such as resizing or closing the window. Even worse, if your application is not responding to events then that may cause other applications to freeze, as they may send your application a message and be stuck waiting for a reply.

If you have to do a lot of processing then either check for messages periodically, or do the work in a separate thread.

-1
votes

create a thread for extensive drawing on a cache bitmap. while bitmap is not ready just print on WM_PAIN event "processing please wait..." for example. when ready print that bitmap. and destroy the thread.