Tips on the use of timers
Hello all,
I have been having a little bit of trouble lately with a program that I am using in an experiment. At the moment its running on about 20 computers in various schools. On two computers, that have an AMD K6 CPU, errors have been reported. From what I have seen it has something to do with Kernel32.
But to get to my point, I believe it has something to do with the timers that I am using in the main interaction screen. It is perhaps possible that timer wants attention when it is no longer possible creating some kind of error with windows.
What I would like to know are their any sound pointers to the use of timers? For example, should you activate them only when a form is activated? and disable them when focus to the form is lost? When the form is closed should you switch off the timers first? How do people feel about using multiple timers?
Ralph
Hi Czar,
Starting a timer by itself in the form onCreate is not a problem , however, if your timer is calling a procedure or function that requires an object that is not yet loaded, you will definitly run into problems.
OnShow is a bit later in the execution of the program so you might want to start it then.
Basic rule would be to start with the timer disabled by default and then activate it in your onShow.
Same thing goes for shutting down your app, if you are in the process of freeing a tlist, a record, a D3Dsurface.. etc, and your timer kicks in, then your app will definitly crash.
So make sure you disable you timer(s) before you start cleaning up.
As for multiple timers, you have to be carefull with this one as well, there''s a limit to the number of timers, i can''t remember the exact number but i think it''s around 12 or 14.
And the limit on precision timers is even lower.
I never had the need for more than one timer myself.
It would make an application very unpredictable and very tuff to synch.
Re-thinking your approach will probably make those extra timers obsolete
I hope this helps a bit,
Best regards,
Gunner.
Starting a timer by itself in the form onCreate is not a problem , however, if your timer is calling a procedure or function that requires an object that is not yet loaded, you will definitly run into problems.
OnShow is a bit later in the execution of the program so you might want to start it then.
Basic rule would be to start with the timer disabled by default and then activate it in your onShow.
Same thing goes for shutting down your app, if you are in the process of freeing a tlist, a record, a D3Dsurface.. etc, and your timer kicks in, then your app will definitly crash.
So make sure you disable you timer(s) before you start cleaning up.
As for multiple timers, you have to be carefull with this one as well, there''s a limit to the number of timers, i can''t remember the exact number but i think it''s around 12 or 14.
And the limit on precision timers is even lower.
I never had the need for more than one timer myself.
It would make an application very unpredictable and very tuff to synch.
Re-thinking your approach will probably make those extra timers obsolete
I hope this helps a bit,
Best regards,
Gunner.
The limit on the number of timers only really matters on older systems such as Windows 3.x. 95, 98, NT and later versions of Windows have potentially thousands of timers.
Since the OnTimer event is triggered by the processing of a WM_TIMER message, it will not interrupt any code that is currently executing. This is a common misunderstanding. The code currently executing must finish and allow the message loop to run through before the OnTimer event will be triggered. This is also why it is a BAD THING to call Application.ProcessMessages inside another function. Therefore, you will not get an OnTimer event during cleanup, but a WM_TIMER event may be added to the message queue during the code. However this message will not be processed until the next run through the message loop.
Steve ''Sly'' Williams Code Monkey Krome Studios
Since the OnTimer event is triggered by the processing of a WM_TIMER message, it will not interrupt any code that is currently executing. This is a common misunderstanding. The code currently executing must finish and allow the message loop to run through before the OnTimer event will be triggered. This is also why it is a BAD THING to call Application.ProcessMessages inside another function. Therefore, you will not get an OnTimer event during cleanup, but a WM_TIMER event may be added to the message queue during the code. However this message will not be processed until the next run through the message loop.
Steve ''Sly'' Williams Code Monkey Krome Studios
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement