I found this code. But i would like to know if is possible that instead of intervat program will start every day at 3 am?
edit: code
http://www.codeguru.com/forum/showthread.php?t=483012
thx
You can accomplish this using Task Scheduler, no need for controlling this programmatically. Unless its a windows service you are implementing, in that case you would need to check the time on the hour and do your processing respectively (and that's not taking into account if your using different timezones)
I'm afraid that if you are not using the task scheduler your service will have to run continuously. You need to change the example you link to as follows:
The example code you link to uses an interval of 2 seconds. You may shorten the length of the interval to 1 second or even less.
The implementation of the OnTick(...) method should check if it's 3AM. If this is the case, do whatever it is you need to do.
Related
Forgive me for this question, but I can't seem to find a good source of when to use which. Would be happy if you can explain it in simple terms.
Furthermore, I am facing this dilemma:
See, I am coding a simple application. I want it to show the elapsed time (hh:mm:ss format or something). But also, to be able to "speed up" or "slow down" its time intervals (i.e. speed up so that a minute in real time equals an hour in the app).
For example, in Youtube videos (* let's not consider the fact that we can jump to specific parts of the vid *), we see the actual time spent in watching that video on the bottom left corner of the screen, but through navigating in the options menu, we are able to speed the video up or down.
And we can actually see that the time gets updated in a manner that agrees with the speed factor (like, if you choose twice the speed, the timer below gets updated twice faster than normal), and you can change this speed rate whenever you want.
This is what I'm kinda after. Something like how Youtube videos measure the time elapsed and the fact that they can change the time intervals. So, which of the two do you think I should choose? Timer or StopWatch?
I'm just coding a Windows Form Application, by the way. I'm simulating something and I want the user to be able to speed up whenever he or she wishes to. Simple as this may be, I wish to implement a proper approach.
As far as I know the main differences are:
Timer
Timer is just a simple scheduler that runs some operation/method once in a while
It executes method in a separate thread. This prevents blocking of the main thread
Timer is good when we need to execute some task in certain time interval without blocking anything.
Stopwatch
Stopwatch by default runs on the same thread
It counts time and returns TimeSpan struct that can be useful in case when we need some additional information
Stopwatch is good when we need to watch the time and get some additional information about how much elapsed processor ticks does the method take etc.
This has already been covered in a number of other questions including
here. Basically, you can either have Stopwatch with a Speed factor then the result is your "elapsed time". A more complicated approach is to implement Timer and changing the Interval property.
When I profile my application , it seems that 70% of the time is spent in the method:
Microsoft.Practices.EnterpriseLibrary.Configuration.Storage.ConfigurationChangeWatcher.Poller()
From what I can gather this method should only be invoked every 50 seconds so I find it hard to believe that it is actually taking up that much time.
Does anyone know how can I reduce the frequency that this method is called?
I'm surprised that in an application that is doing real work that a timer thread that executes once every 15 seconds (the default) and looks to just be comparing file times is taking up so much time.
What if you try to set the timer interval to a longer interval sometime after initializing Enterprise Library:
ConfigurationChangeWatcher.SetDefaultPollDelayInMilliseconds(int.MaxValue);
If you do that does the time spent decrease?
Also, if you use the FileConfigurationSource class programmatically there is a constructor overload to disable watching for configuration file changes.
I have a program that displays some information in the form of a chart. The information updates every month and so i need to retrieve the information once a month.
I thought about having a thread that sleeps for a months time but, i don't know if that is doable. Can someone suggest a better way to do this?
thanks!
You can store the last accessed date in a file/table and then poll the file/table each day when the program starts. If it exceeds 1 month(30/31 days) then re-get your data.
Use the DateTime class in .NET to help you with it. Also use DateTime.Subtract() between two dates.
I'm wondering what you're trying to do here. It sounds... odd.
So, where is the info coming from? A database? If so, can you just calculate the month's values when pulling the data normally? Or you could have a job running in SQL Agent that updates a table once a month with the calculated values.
Really with windows you could set up a scheduled task with a similar concept. It runs once a month and pulls down the new data.
But basically a little more info about what you're trying to do might help us give you better answers..
I have seen implementations where on startup a thread is started and calculates the time until the next read time. Within the thread it waits for a shutdown event to be signalled (which is fired by the app), the timeout value is the previously calculated time. Once wait is complete, if it wasn't due to shutdown event, then data is read.
However, the more common implementation that I have seen is to use scheduled tasks to load the data to the app. Although this will take longer to implement than threaded version, it should provide a more robust solution.
I created an App which uses Timer class to callback a method at a certain time of a day and recall it every 24 hours after that.
I use Ticks to signify 24 hours later. (int) TimeSpan.FromHours(24).TotalMilliseconds
I use that to retrieve the ticks for 24 hours.
This works fine for me but on different computers, the trigger time is way off.
Anyway to debug this ? How should I fight/handle this issue ....
How much is "way off" to you? If you want an app to run at a specific time, schedule it for that specific time, not 24 hours from the time it finishes - you're inevitably going to see some slippage doing it that way because the time will always be off the next day X seconds, where X is how long the program took to complete the previous day.
How "way off" yes desktop computers clocks frequently fluctuate by a second or more every day, they generally use a NTP server to correct these fluctuations. But its just the nature of the beast.
First of all, there is no "my ticks" because a Tick is a well-defined value.
A single tick represents one hundred nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond.
A DateTime object also has a Ticks property that you can use to access it. I wrote some simple code that I've posted here worked great for me, producing perfect results.
I see no reason your implementation should drift so much. Please make a sample that consistently produces the problem or post the relevant pieces of your own source.
I have an app that needs to fire off a couple of events at certain times during the day - the times are all defined by the users. I can think of a couple of ways of doing it but none of them sit too well. The timing doesn't have to be of a particularly high resolution - a minute or so each way is fine.
My ideas :
When the app starts up read all the times and start timers off that will Tick at the appropriate time
Start a timer off that'll check every minute or so for 'current events'
tia for any better solutions.
Store/index the events sorted by when they next need attention. This could be in memory or not according to how many there are, how often you make changes, etc. If all of your events fire once a day, this list is basically a circular buffer which only changes when users change their events.
Start a timer which will 'tick' at the time of the event at the head of the list. Round up to the next minute if you like.
When the timer fires, process all events which are now in the past [edit - and which haven't already been processed], re-insert them into the list if necessary (i.e. if you don't have the "circular buffer" optimisation), and set a new timer.
Obviously, when you change the set of events, or change the time for an existing event, then you may need to reset the timer to make it fire earlier. There's usually no point resetting it to fire later - you may as well just let it go off and do nothing. And if you put an upper limit of one minute on how long the timer can run (or just have a 1 minute recurring timer), then you can get within 1-minute accuracy without ever resetting. This is basically your option 2.
Arguably you should use an existing framework rather than rolling your own, but I don't know C# so I have no idea what's available. I'm generally a bit wary of the idea of setting squillions of timers, because some environments don't support that (or don't support it well). Hence this scheme, which requires only one. I don't know whether C# has any problems in that respect, but this scheme can easily be arranged to use O(1) RAM if necessary, which can't be beat.
Have a look at Quartz.Net. It is a scheduler framework (originally for Java).
This sounds like a classic case for a Windows Service. I think there is a Windows Service project type in VS2005/2008. The service coupled with a simple database and a front-end application to allow users to set the trigger times would be all you need.
If it won't change very often, Scheduled Tasks is also an option.
I've written a few programs along these lines.
I suggest #2. All you need to to is keep a list of times that events are "due" at, and every X amount of time (depending on your resolution) check your list for "now" events. You can pick up some optimization if you can guarantee the list is sorted, and that each event on the list is due exactly once. Otherwise, if you have recurring events, you have to make sure you cover your window. What I mean is, if you have an event that is due at 11:30 am, and you're checking every seconds, then it's possible that you could check at 11:29:59, and then not again until 11:31:01, due to the inprecision of the CPU time-slices. So you'll need to be sure that one of those checks (11:29 or 11:31) still picks up the 11:30 hit, and that ONLY one of them does (i.e., you don't run at both 11:29 and 11:31).
The advantage this approach has over checking only on times you know to be on your list is that allows your list to be modified by 3rd parties without your knowledge, and your event handler will continue to 'just work'.
The simplest way would likely be to use Windows scheduler.
Otherwise you need to use one of the Timer classes, calculating how long until the first event. This approach, unlike the scheduler, allows new events to be found by the running process (and, possibly, resetting the timer).
The problem with #1 is that the number of milliseconds before an event may be too large to store in the Timer's interval, and as the number of events increase, your number of timers could get unweildly.
I dont see anything wrong with #2, but I would opt for a background worker or a thread.