🚀 go-pugleaf

Robert G. Hoover wrote:
> Do the WM_TIMER messages pile up in the Windows Queue and execute when
> the last one finishes?

AFAIK, yes.

> If so, then what happens at the end of the
> program? Do all the unhandled WM_TIMER messages disappear as the program
> has ended?

No, again, AFAIK, they'll all fire before the program closes.

> Does that mean that the longer my program runs, the longer
> and longer the message queue will get until Windows suffocates?

No, Windows has a internal limit on the no. of messages that the queue can 
hold. However, this limit is rather high. Once you reach that limit, AFAIK, 
Windows will just stop adding messages.

Jon 

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?

Robert G. Hoover wrote:

And just to prove it for yourself

Add this to your favourite WinApp

In File Global Area:
static	int	counter[2] = {0,0};
static	int	counter_number = 0;

In  WinProc():
	In	 case WM_CREATE:
			SetTimer( hWnd, 0, 200, NULL );
			SetTimer( hWnd, 1, 10000, NULL );
	Add
		case WM_TIMER:
		switch (wParam) 
		{ case 0:
			++counter[counter_number];
			Sleep(210); 
			return 0;
		case 1:
			if( counter_number )
			{	PostMessage( hWnd, WM_CLOSE,0,0);
				KillTimer( hWnd, 1 );
				return 0;
			};
			++counter_number; 
			KillTimer( hWnd, 0 );
			return 0; 
		}; 
		break;
In  WinMain() just before return:

	char	results[1024];
	wsprintf( results,	" Number of 200ms messages processed"
			" in 10 seconds: %i\r\n"
			" Number of 200ms messages processed"
			" after timer killed: %i\r\n",
					 counter[0],counter[1]);
	MessageBox( 0, results, "TimerCheck", MB_OK );

My result was 47 and 0

Ed Mulroy wrote:
> 
> WM_TIMER messages typically come in at multiples of 55 milliseconds and

Different versions of Windows may use different timing.  Maybe Windows 
95/98 used the original PC default timing of 18.2 Hz.  On my Windows XP 
desktop direct measurement using GetTickCount() shows an interval of 15 
or 16 milliseconds with an average of 15.625ms corresponding to 64Hz. 
This correlates with measurements using GetTickCount() on the same machine:

Timer::Interval		Measured interval	Fractional seconds
200			203 or 204		13/64
210			218 or 219		14/64
220			234 or 235		15/64
230			234 or 235		15/64
240			250			16/64
250			250			16/64

The GetSystemTimeAdjustment function also gives the time period between 
the system's clock interrupts which on my system is again 15625.0 
microseconds (64 Hz).

-Eliot

I did not know that.  Thanks, that's good information!

.  Ed

> Eliot Frank wrote in message
> news:46716e05@newsgroups.borland.com...
>>
>> WM_TIMER messages typically come in at multiples of 55
> milliseconds and
>
> Different versions of Windows may use different timing.  Maybe Windows 
> 95/98 used the original PC default timing of 18.2 Hz. On my Windows XP 
> desktop direct measurement using GetTickCount() shows an interval of 15 or 
> 16 milliseconds with an average of 15.625ms corresponding to 64Hz. This 
> correlates with measurements using GetTickCount() on the same machine:
>
> Timer::Interval Measured interval Fractional seconds
> 200 203 or 204 13/64
> 210 218 or 219 14/64
> 220 234 or 235 15/64
> 230 234 or 235 15/64
> 240 250 16/64
> 250 250 16/64
>
> The GetSystemTimeAdjustment function also gives the time period between 
> the system's clock interrupts which on my system is again 15625.0 
> microseconds (64 Hz).