>Rick,
>Thanks for the reply. The firing interval indicated in my original message might have been a little high (and will be user defined i.e. the user can change it) but it probably will not be less than one second.
>
>Have you ever created a windows service that is using a timer in this way before? Any comments would be appreciated.

Yes. Web Monitor uses timers in a similar way and it works great.

I think you may be thinking of VFP or VB timers which were very inefficient because they didn't use threads to manage their timing calls which could result in missed timer events etc. Timers are reliable because they are running on separaet threads and don't need to directly synchronize with the rest of the app - your code fired through the event handler does though <g>.

Once a second is a life time in processort time... you just want to try to minimize overlap of timer event handlers because each timer uses a .NET Threadpool thread. If you have overlap more than one thread may be used at a time which may or may not be a problem since hte pool is limited in size.


+++ Rick ---


>
>Thanks again for your reply and explanation.
>
>Sincerely,
>Einar
>
>>Einar,
>>
>>Timers are pretty efficient. They're basically a threading mechanism that fires off new threads (or threadpool threads really). If I remember right these timers are pretty close to underlying OS APIs so there's very little overhead for them, especially in low firing intervals as yours (many seconds).
>>
>>Remember too that timers fire events on a separate thread, so they don't genearlly hold up the main app. Just make sure you keep the code in the handler simple and quick and if it's not to utilize Application.DoEvents() liberally.
>>
>>+++ Rick ---