A special (?) type of timer

  • Thread starter Thread starter adi
  • Start date Start date
A

adi

Hi

I need the following: at particular times of day, I want to make some
processing.
System.Windoes.Timer doesn't help much, because it exposes the Interval
property.
Instead, I need to tell the timer: fire at 3:25 pm.

What's the best way to accomplish that?

Thanks.
 
Hi,

I'm not sure if there are any classes in the framework that will do that. I assume there is some unmanaged API that you can use
instead, or you could try using a System.Threading.Timer with a 1 hour interval, for example, and after it fires each time check the
current time. I know it seems sloppy but there is more of a chance that your timer will miss firing at the appropriate time of day
using a 24 hour interval then a 1 hour interval because the clock may be changed by the user or some online time synchronization
service (for instance, day light savings). The smaller the interval that you choose the better the accuracy in those situations.

Great question. Please let us know what you decide to use or if you find anything better.
 
Hi
I need the following: at particular times of day, I want to make some
processing.
System.Windoes.Timer doesn't help much, because it exposes the Interval
property.
Instead, I need to tell the timer: fire at 3:25 pm.

What's the best way to accomplish that?

Thanks.
Click to expand...

Scheduled tasks? If it's only at certain times, why have the program
running the entire day?
With Scheduled Tasks you can specify that some program is run at
specific times.

Hans Kesting
 
Of course one solution is to set the timer's interval to 1000 and
constantly check the time.
This seems to me like "guessing" rather than going straight forward.
I also found a way to set a large interval to the timer:

http://support.microsoft.com/default.aspx?scid=kb;en-us;180736

This seems to be a more professional way to solve the problem.
But still I hope there's another cool trick to solve this.

....or not?
 
Hi Dave,

Thanks for your quick input.
I was already posting a new message when yours came.
Please check my earlier message, I found an acceptable solution
(http://support.microsoft.com/default.aspx?scid=kb;en-us;180736)
I say it's only "acceptable" because the solution make use of APIs. Not
that it's a bad thing.
Anyway, I keep my eyes on this thread, hoping for more solutions -
hopefully without using APIs, or using better APIs :)

Cheers.
Adi.
 
Hi Hans

Good question.
I really could use this, if my application was very very specific.
What about large applications that need to keep running and also need
to execute specific tasks at specific hours of days?

Ok, you may reply that for these (small) tasks I should create a
specific app that will be scheduled by the main app. Not a bad ideea
too, but the tasks depend on my main app's context (e.g. some running
values).

You also may reply that I could exchange data between the two
processes.
Yes, I could, but the fact would be that I would have solved a problem
by falling into another problem (e.g. process intercommunication in a
concurential environment, like Windows). This new problem also has
solutions (worse or better), but my first problem also has worse or
better solutions :)

Adi.
 
Now that you mentioned, I'm pretty interrested how Windows' Scheduler
works.
Does it "listen" the clock somehow? Does it make use of timer(s)?
Pretty much to explore here.

Adi.
 
Hi,

Use a scheduled task better, look in the archives as I remember somebody
posting a way to programatically schedule a task
 
Hi Adi,

I'm not 100% sure, but I believe that System.Windows.Forms.Timer wraps that API function. A similar managed function can be found
in the Microsoft.Win32.SystemEvents class.

I'm not so sure there is really any benefit using that API over either managed class. However, I recommended to use a threading
Timer (or at least the service timer, System.Timers.Timer) so there is no coupling with a window handle and message loop. In other
words, using that API or the System.Windows.Forms.Timer you'll have to specify a Control handle. Also, all of them, including the
SystemEvents timer, are just as succeptible to the day light savings issue that I mentioned, so you might as well just use the
threading Timer.

Managed Timers on MSDN:
http://windowssdk.msdn.microsoft.com/en-us/library/zdzx8wx8.aspx
 
Hi Ignacio,

I'd be concerned with breaking encapsulation if the user could simply delete the task when they identify it as something "they
didn't put there". Then what does the program do? It would simply miss events. Seems a bit sloppier than my sloppy solution ;)

Of course I'm just assuming that the COM API will always cause a new task to appear in the user's Scheduled Tasks list, but I could
be wrong.
 
Your question made me curious, so I did a little research, specifically
about the Windows W32Time Service. A Technet article I read indicates that
the way it synchronizes time is by polling. That is, at regular intervals,
it uses SNTP (Simple Network Time Protocol) to query the configured Time
Server for the correct time, and adjusts its settings accordingly. I would
therefore think that emulating this behavior by implementing a class that
polls the OS for the time at intervals would be your best bet.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.
 
adi said:
Of course one solution is to set the timer's interval to 1000 and
constantly check the time.
Click to expand...

The System.Threading.Timer has a max. period of 4.294.967.294 ms
thats about 49 days, that should be suficcent.
It's twice the max. period of the API the article mentions.
This seems to me like "guessing" rather than going straight forward.
I also found a way to set a large interval to the timer:
Click to expand...

This is not "guessing" but "polling" (= looking from time to time, if there
is something to do.
I guess, the task scheduler is doing something very similar.
If this is not precise enough, you could test, if the due time is within the
next period and then set the exact rest interval.
 
Hi Kevin

It seems to me that this solution could be costly if I needed more
accuracy on my timer.
I think that the cost in terms of resources grows exponentially while
increasing accuracy.
Also, we should not forget that a timer is a system resources and
firing it's event gets also system resources, thus impacting the
overall system performance.
I think I will try using a timer and set its interval to high values,
as suggested by the article I mentioned earlier:
http://support.microsoft.com/default.aspx?scid=kb;en-us;180736
This way, I get rid of redundant events triggered by the timer on a
periodical basis. I don't want to make on purpose things complicated,
but I think that this is the more efficient (not necessarily the best)
solution.

It still remains a little problem for me: is the timer reliable enough
so I can trust the fact that I don't miss any trigger at all? I mean,
if I put a timer to check the time once a second (Interval = 1000),
it's no problem to miss a trigger (I couldn't figure out right now such
a situation) because it's very likely that I don't miss the second
trigger, which fires one second later.
On the other hand, the solution embraced by me is more efficient, but
if somehow I "miss" a trigger, my event will only have another chance,
say, next day.


Kevin Spencer a scris:
 
Hi Adi,

I wouldn't worry about cost at all. The System.Threading.Timer just waits on a TheadPool thread. Your application isn't going to
be doing anything each time code is executed during a poll that will be detrimental on performance or use any system resources. It
should just check to see if the processing should occur immediately or if it needs to continue waiting. A single waiting thread
that polls at a reasonable interval should be just fine. e.g., Once an hour, as I suggested to check for daily intervals, or even
once a minute if you'd like to increase the accuracy.

You really don't have to be concerned about missing notifications if you are using a System.Threading.Timer. You would, however, if
you used the System.Windows.Forms.Timer:

Comparing Managed Timers on MSDN:
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/
 
Dave,

Great article.
I will use an System.Threading.Timer object with initial timer event
schedule.



Dave Sexton a scris:
 
A System.Timers.Timer has a very small footprint. If you have one polling
the time at 1-second intervals, it isn't going to even show up visibly in
Task Manager. All your class has to do is raise an event when the time, as
fetched via the polling Timer, is one or more of the specified scheduled
times that you want to run some other process. I have a couple of Windows
Services on a Windows 2003 Server, that use a total of 4 timers, and have
had all timers firing 4 different processes off at 3-minute intervals. These
services have been running for over a year without any problems. The
processes that you're scheduling will use much more of the system resources.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.
 
Hi,

Dave Sexton said:
Hi Ignacio,

I'd be concerned with breaking encapsulation if the user could simply
delete the task when they identify it as something "they didn't put
there". Then what does the program do? It would simply miss events.
Seems a bit sloppier than my sloppy solution ;)
Click to expand...

Well, the user could delete your app altogether :)

IMO it's the best solution, at least I would use it.
Of course I'm just assuming that the COM API will always cause a new task
to appear in the user's Scheduled Tasks list, but I could be wrong.
Click to expand...

Not sure neither. In my case I tell the user that I did added a scheduled
job, if they delete it and the data is not updated (happened once @ a
client) I charge him 150USD to "solve" the problem :)
 
Back
Top