🚀 go-pugleaf

In addition to what Mr Benedicto said:

WM_TIMER messages typically come in at multiples of 55 milliseconds and 
therefore the 200 millisecond setting is nominal, not precise.  Additionally 
they have lower priority than many other messages so timing that uses them 
may be even a bit less precise.  For more precise timing consider using the 
Multimedia Timers.

http://tinyurl.com/yqf97o
    or, in its long form
http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_multimedia_timers.asp

.  Ed

> Robert G. Hoover wrote in message
> news:4670167b@newsgroups.borland.com...
>
> Would you please checkpoint my understanding of the WM_TIMER
> and the Windows Message Queue?
>
> As I understand the process, if I create a TTimer with BDS C++ Builder
> 2006 and set the Interval to 200 milliseconds, a WM_TIMER event will
> fire by Windows and be processed by my application every 200
> milliseconds. If my Timer function code requires more than 200
> milliseconds to complete, then the app will just miss the next
> WM_TIMER event and process the following one?
>
> For example, my 200 millisecond timer executes code that takes 210
> milliseconds to complete. Therefor, my application (a video stream)
> will show a frame rate of 2.5 frames per second instead of the
> desired 5 frames per second because it missed an event and must
> wait 190 milliseconds for the next one?
>
> -- OR --
>
> Do the WM_TIMER messages pile up in the Windows Queue and
> execute when the last one finishes? If so, then what happens at
> the end of the program? Do all the unhandled WM_TIMER messages
> disappear as the program has ended? Does that mean that the
> longer my program runs, the longer and longer the message queue
> will get until Windows suffocates?