Re: bogus timer id in wxTimerProc

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@...