bogus timer id in wxTimerProc

[-JM]

This assert message is occasaionally generated by timers in debug
builds of my app, even under seemingly normal conditions. It originates
from wxTimerProc in msw/timer.cpp. I wonder whether this should really
be considered reason for an assert message under MSW. The doc for the
Win32 KillTimer function explicitly states that it doesn't remove any
WM_TIMER messages already posted to the message queue. So, wouldn't a
call to Stop on a wxTimer around the same moment as when it should have
fired risk running into this situation?

-JM


---------------------------------------------------------------------
To unsubscribe, e-mail: wx-dev-unsubscribe@...
For additional commands, e-mail: wx-dev-help@...

[Vadim Zeitlin-3]

On Fri, 10 Feb 2006 14:43:09 +0100 -JM <jm@...> wrote:

J> This assert message is occasaionally generated by timers in debug
J> builds of my app, even under seemingly normal conditions. It originates
J> from wxTimerProc in msw/timer.cpp. I wonder whether this should really
J> be considered reason for an assert message under MSW. The doc for the
J> Win32 KillTimer function explicitly states that it doesn't remove any
J> WM_TIMER messages already posted to the message queue.

 AFAIK WM_TIMER messages are not posted to the queue, they're artificially
generated when the timer expires and the application is ready to process
them. So I find it somewhat surprizing that there are any timer messages
remaining in the queue. But if this is really the case we should be able to
remove them with PeekMessage().

J> So, wouldn't a call to Stop on a wxTimer around the same moment as when
J> it should have fired risk running into this situation?

 Can you reproduce this in a simple example?

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: wx-dev-unsubscribe@...
For additional commands, e-mail: wx-dev-help@...

[-JM]

On 11 Feb 2006, at 3:36, Vadim Zeitlin wrote:

> AFAIK WM_TIMER messages are not posted to the queue, they're  
> artificially
> generated when the timer expires and the application is ready to  
> process
> them.

This is what Microsoft's documentation of the KillTimer Function says  
on the subject:

     Remarks: The KillTimer function does not
     remove WM_TIMER messages already posted
     to the message queue.

This seem to imply that messages are indeed posted to the message  
queue, and calling KillTimer will not automatically remove any  
message that has already been queued. At least that's my interpretation.

> But if this is really the case we should be able to
> remove them with PeekMessage().

Yes, that may be a possible solution, assuming you want to complicate  
the wxTimer::Stop with mucking with the message queue. Perhaps it's  
possible, after stopping a timer, to calculate the elapsed time and  
compare this to the duration of the timer, and only attempt to remove  
the message if it's clear that the timer may have fired? Or perhaps  
PeekMessage is cheap enough to not worry about optimiszing it away.  
Also, can there be issues with wxTimer::Stop being called on another  
thread than the one managing the message pump?

For now, I've simply removed the "bogus timer ID" assert message also  
in debug builds. In release builds, it already ignores "bogus timer  
ID messages" silently.

>  Can you reproduce this in a simple example?

I see it every now and then in my application - particularly in cases  
where we re-start a timer with a short interval frequently (related  
to drag operations UI feedback). It's possible that I could come up  
with a small example that shows this behavior. But since KillTimer  
(which is called by wxTimer::Stop()) apparently *can* leave stale  
WM_TIMER messages in the queue, I'd say it's quite clear without any  
further proof - at least to me, since I've seen it happen.

The actual likelihood of Stop() causing a "bogus timer" assertion is  
quite rare, since Stop would have to be called very close to the  
point where the timer fired. Not impossible, but statistically rare  
in most apps, which may be why I only see this every once in a while.

-JM


---------------------------------------------------------------------
To unsubscribe, e-mail: wx-dev-unsubscribe@...
For additional commands, e-mail: wx-dev-help@...