Avatar of charles_gilley
 asked on

What happens to WM_TIMER events from SetTimer when they are not handled?

Curiosity question - suppose I have a dialog that draws something in response to an WM_TIMER event.
In the OnInitDialog method, I call SetTimer(nTimer, 1, NULL); for a 1mSec update.  It doesn't matter that
the interval is not predictable, what does matter is that the time spent in OnTimer is >> than the timer
interval (meaning WM_TIMER events should be piling up).

Does mfc or Windows or the message pump have any built in protection to deal with this situation?
I have heard it alleged that the events will leak memory, but I am dubious of this allegation.

Thanks for any insights...
System Programming

Avatar of undefined
Last Comment

8/22/2022 - Mon

The WM_TIMER event is only sent if there are non waiting in the queue - so, yes, windows does have a built in protection

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question

Just to be on the safe side I have done some quick testing and found it is a mixture of both my previous comments.

If the calculation (or whatever) in the OnTimer fn does not generate another message loop (eg AfxMessageBox, dlg.DoModal) then it is perfectly safe, windows will not generate extra WM_TIMER messages until AFTER the function exits.

However if you create another message loop eg with a message box or displaying another modal dialog then you need to explicitly use KillTimer....SetTimer block inside the OnTimer function.

Andy - the good news is that I am not using mutliple message pumps, so I don't need to worry about this variation.
The real issue is what happens when the OnTimer processing "stalls" message processing.

If I understand this correctly, Windows "knows" that my application is handling a timer event and holds off generating another event?
And, if I might extend the issue a bit further, let's say I have two timers firing.  Windows distinguishes between different timers?

Is there any Microsoft documentation to describe the internal workings of the SetTimer implementation and what you are saying?

Appreciate the data so far...  I'm increasing the points, because this topic is about to get a bit deeper....
All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck

You can test the behaviour easily.
Create a timer that fires rapidy ( SetTimer(1,1,NULL); )
In the OnTimer put code like

TRACE("OnTimer - start ");
for(long x = 1000000; x; x--)
//maybe extra loop in here to slow it down further.  DEBUG build else you don't see the trace ouput
TRACE("OnTimer - stop\n");

You should see in the output window  a long wait between the start and stop messages, and each start is matched with a stop message.

Two timers.  The function has a parameter - that is the ID of the TIMER event that is fired so you need a simple if..else (or switch) statement.  Note that if the main thread is blocked by the processing you may not get the behaviour that you desire.  (You might want to think about spawning a thread).

Documentation - There is a variety of information in the help files - see SetTimer, Timers, WM_TIMER....

Clean up time.  The reason I asked this question is I have a Windows CE / mfc application that simply "loses" timer events.  I put loses in quotes, because what I see is the timer stop occurring.  Go off and do something on another window, and the timers resume.  Something is definitely odd here.  Anyway, with Windows, you can always learn at least one new thing a day.

Thanks for the help.
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.