A customer was worried that they may have a problem with their message queue filling with WM_TIMER messages. “If my WM_TIMER handler takes longer than the timer period, will my queue fill up with WM_TIMER messages?” As we should know by now, timer messages are generated on demand:

The WM_TIMER message is a low-priority message. The Get­Message and Peek­Message functions post this message only when no other higher-priority messages are in the thread’s message queue.

Here’s the basic algorithm. (I’m ignoring filtering and I’m assuming that messages are removed.)

• Look for a posted message. If one exists, then return it.
• Was Post­Quit­Message called? If so, then generate and return a WM_QUIT message.
• Look for an input message. If one exists, then return it.
• Did the mouse move since the last call? If so, then generate and return a WM_MOUSE­MOVE message.
• Does a window need to be repainted? If so, then generate and return a WM_PAINT message.
• Is there a timer that has elapsed? If so, then generate and return a WM_TIMER message.

Notice that the generated messages are generated on demand by message retrieval functions. If you never call a message retrieval function, then no messages are generated. And in the case where the messages are removed (i.e., you use Get­Message or you use Peek­Message with PM_REMOVE), the messages are removed immediately after being generated, so they don’t hang around very long at all.

In particular, if your WM_TIMER handler takes longer than the timer period, and it doesn’t call a message retrieval function, then there is no opportunity for another WM_TIMER message to be generated. Only when you call a message retrieval function does there become a possibility for a WM_TIMER message to be generated.