I'm sure this has been dealt with before, but I didn't know how to
accurately 'google' it....

I have created a VB6 application that needs to run one of its
procedures every 24 hours.  Since the VB6 timer has a maximum interval
of about a minute, it seems like I would be having my code compare
dates 1440 times a day every day from here to... well it could be
months or years.

I know this may sound dumb, but is this kind of 'overhead' okay for
most computers?  (For all I know, this may be one of the least taxing
things a computer can do perpetually, but I don't know this, which is
of course why I'm asking).

If you have a suggestion in terms of a better way of going about this,
I'd be open to hearing it.  I now know the 'Task Scheduler' might
handle similar needs to mine, but I'm hoping I can create an app that
handles its own duties in this regard.  In other words, I don't want
an outside process handling this duty; if I can avoid it.

I look forward to your feedback.  Thanks in advance.

Alan Mailer wrote:
Show quoteHide quoteNo sweat.  That's an extremely minimal impact on any system, including one
built 20 years ago and running Windows 1.0!  :-)

You could also look at the concept of "waitable timers" but if your
application needs to be doing anything else during the lull times that may
not be such a great idea.

Show quote Hide quote You could up that to once per second and the PC would still not be taxed at
1% of 1%. This might be necessary because you will have a potential error of
1 minute if you have the timer fire once per minute.

Michael

Michael C wrote:

I'd have the timer adjust its own rate as the target time comes closer.

I've got some well-tested code someplace, but I'm not at home right now to look it up.
If I recall correctly, it sets the Interval to 65535 until the time remaining is
less than 5 minutes, then to 1000 until the time remaining is less than 5 seconds,
then to 50 until done.



    Bob

Show quote Hide quote That's a good idea, you could leave it a 65535 until the very last tick
though.

Show quoteHide quote

Michael C wrote:
Show quoteHide quoteYou could try, but then you'd *frequently* miss the target by over a minute.

Windows is just not capable of real-time performance.



    Bob

Why? Code would be something like this:

Timer1_Tick
     t = GetTicksToTimeIWant
     if t > 65535 then t=65535
    Timer1.Interval = t
End Sub

Wouldn't that pretty much land right on it?

Michael

Michael C wrote:
Show quoteHide quoteIf absolutely nothing else is running on the same PC, then ... sometimes.
Maybe even "fairly often"

But a significant portion of the time one timer event will be
"pretty close" like maybe 65540 away, but won't trigger the adjustment,
and then the next timer event will get delayed a few ticks by other processes.



    Bob

I still don't get it, maybe I'm missing something. I agree it is possible
that a timer event can get delayed due to some process hogging 100% cpu or
whatever but this would be the same problem if the timer was at 65000 or
10ms. Wouldn't it?

Michael

Welcome to the world of Windows Timers.

A)  Windows is not, and never was intended to be, a Real Time OS.
B)  In Windows, Timers have the second lowest priority in the system of all
system messages.
C)  The third thing to remember is that Timers run off the system clock,
which only ticks 18.2 times per second.

Now for the impact -

1)  You can not depend on any application to run at a specific speed or
time - see A, B, and C.
2)  Timers have a delay quantum of about 55 milliseconds - see C
3)  If the application message queue has any messages in it other than a
message to repaint it's windows, a timer message won't be placed in the
queue and you will have to wait for the next clock tick - see C and B
4)  These caveats apply to Sleep as well as it uses a timer internally.

The upshot is that you can't depend on Windows to trigger on the
millisecond.  If you system is very heavily loaded or there are a lot of
messages going to your application, timer messages, which VB converts to the
Timer events may get delayed, possibly forever.  But you will probably be
noticing other performance issues before this happens, so it's not a real
big issue.  The VB timer component uses the basic Windows Timer API for its
operation, so it is constrained by A, B, and C above.  Task Manager also
uses this API.  There is no API to put a program to sleep until a certain
time - what you need to do is compute the amount of time to your desired
time and set your timer for that delay.

If you want millisecond accuracy within the constraints of A above, you must
use the API's multimedia timers.

Mike Ober.


Show quoteHide quote

Right, but exactly none of that is relevant to the question at hand. I don't
see how bob's method would be any more accurate than mine. Maybe I'm missing
something but I'm interested to know what.

Michael

Simple, if your system is heavily loaded when you expect the 24 hours to
elapse, there may be a delay in triggering the timer.  Also, anytime you set
a timer or sleep, windows will round it up to the next clock tick, which can
be up to 55 milliseconds after you thought the timer should fire.
Basically, I'm saying your app needs to check the actual clock time if it is
millisecond sensitive to the actual time it wakes up.

Mike.

Show quoteHide quote

You're missing the point. Ok the timer has some inaccuracy, whatever that is
assume we are happy with that and are not interested in increasing it. We
have 2 methods of trigger an event on a certain time. First is the timer is
set to 65535 ms and in each timer event we check how far away the time we
want is. As the time we require approaches we reduce the interval to 1000ms,
the 500, then 50 etc. The second method is just to leave it at 65535 and
check how far away the time we require is, we leave the interval at 65535
until the time we require is less that 65535 ticks away and then set it to
the required interval once. Is there any problem with method 2?

Michael

Michael C wrote:
Reflect on that...

How exactly am I missing the point Karl? Or are you just chucking insults as
usual?

Michael

Michael C wrote:
Wow, that's a rather stunning twist.  I'm not sure, exactly, but you've now
made it clear you did.

Just seems that, according to you, people rather frequently miss your
supposed points.  I think that's something you, or at least most folks,
would find enlightening to reflect upon.

So basically you have no point and are just chucking insults.

Michael did miss the point because we were assuming the vb6 timer was
accurate enough for this task.

Michael

Michael C wrote:
                                                       ^^^^^^^
You seem to have misspelled "incites" -- HTH!

Come one karl, surely you can do better than that. The way you wrote that it
looks like you are saying that you incite insults.

Michael

Michael C wrote:
Heh, you _do_ have problems with subtleties, don't you? <g>

Michael,

Using either algorithm (I would use the second one), as soon as your timer
interval drops below 55, you should start your application since you are now
inside the Windows timer quantum.

Mike Ober.


Show quoteHide quote

I'd use the Task Schedular for this.  It's part of the OS, so I wouldn't
consider it an "outside process".

Mike Ober.

Show quoteHide quote

If the task scheduler is used, does a user need to be logged in?

Thanks
Saga



Show quoteHide quote

Saga wrote:
Nope.  That's one advantage, for sure.  (It'll still require credentials,
though.)

Only if you check the box that requires such a condition.

Understood, thanks to both! :-)

Saga

Show quoteHide quote

multimedia timer
Timeout implementation
How to pass parameter to another program?
Problem displaying a TIFF file
Spreadsheet like control for VB6
Open File For Binary - Works in XP Pro But Fails in XP Home
How can I end my program?
printer margins (ok on first page only)
Why won't VB6 control set install on WinXP pro SP2?
create primary keys on a view