A simple app really. Just threw it together to keep track of how long I've been working on something so I knew how much to bill a client for coding time, documentation time, etc. One could always add "always on top" code should it be desired.
Didn't make allowances for going past 24 hours because, regardless of how intense anyone is, they wouldn't need this app if they were at something that long, they'd need their head examined! [obviously the code could be amended to do that should you really need it]
Here's the code and a screen shot (ID labels added to screenshot so you can tie back to the code; obviously actual form wouldn't have these ID's displayed):
i do remember something from a book that would be of some concern to you, doofusboy. if memory serves right, it is from the black book of vb programming. i wont be able to put the exact sam phrase here but i can put the sense right, if you know what i mean.
while using a timer control may be a very easy way to calculate the time interval of anything, it can also be unpredictable as it gives more preference to other processes running in the system than itself. this infers that if the interval of a timer is set for 60,000 (i.e., 1 min=60 sec), and the computer is going thru some stressful calculations like rendering some 3D pic or animation, or some games, the timer may show your time to be 1 minute but in reality it will exceed the 1 minute mark. so it is not recommended to put all your faith in the timer control if being used for long durations in stressful environments.
of this I was aware, but doesn't generally apply in my case for the development work that I do. but it's a good "heads up" for those that aren't aware of it!
Do canibals not eat clowns because they taste funny?
i am now working on a project based on your clock. i will make the project of three categories; single user, medium user and the massive user. single user, of course, for a single computer. medium user for a lan based workgroup. the massive user will be for a multiple users working with the same project from all around the world. i will have to make a separate server for the multi user support of course.
i am telling this as the closk was your idea and i am building on it. is it okay???
Sure it's OK ! I posted it in hopes it might help someone. Glad you found a use for it !
(keep in mind that I did NOT make allowances for this application to be running for more than 24 hours; although I'm sure it could be enhanced with logic to handle that eventuality)
Perhaps you'll be as kind to share with us what you come up with too ?
Last edited by doofusboy; Jun 1st, 2003 at 06:38 AM.
Do canibals not eat clowns because they taste funny?
I think this was the paragraph you were referring to...
From VB Black Book You shouldn’t count on a timer too closely if your task execution is dependent on exact intervals; if the system is busy executing long loops, intensive calculations, or drive, network, or port access (in which case software routinely disables the timer interrupt), your application may not get Timer events as often as the Interval property specifies. That is to say, Timer events are not guaranteed to happen exactly on time. If you need to be sure, your software should check the system clock when it needs to (using, for example, the Visual Basic Time$ function), rather than try to keep track of time internally.
I was thinking of simply checking Now() at the beginning and end of your app usage to determine the start/end times, as you can see, this text recommends the same thing (but using Time$)...
Is an IF...MAYBE...THEN... clause TRUE half of the time?
From VB Black Book You shouldn’t count on a timer too closely if your task execution is dependent on exact intervals; if the system is busy executing long loops, intensive calculations, or drive, network, or port access (in which case software routinely disables the timer interrupt), your application may not get Timer events as often as the Interval property specifies. That is to say, Timer events are not guaranteed to happen exactly on time. If you need to be sure, your software should check the system clock when it needs to (using, for example, the Visual Basic Time$ function), rather than try to keep track of time internally.
Don't think that is an issue here.
Seems to me that in this case it is more important to let the application get on with its job than to have exactly accurate times - therefore this is a very appropriate use of a timer as it wil do just exactly that.
Brian
(Fighting with the RightToLeft bugs in VS 2005)
Don't think that is an issue here....it is more important to let the application get on with its job than to have exactly accurate times - therefore this is a very appropriate use of a timer as it wil do just exactly that.
How is it not an issue? The "job" of the app is to determine how long itself has been running...why would accurate times not be important? Why is the original program coded to determine SECONDS if this is not important?
I am not sure WHY you would use a Timer to (accurately) determine elapsed time or to keep the current time unless you can be sure no other processes will not interfere with the Timer (but why take the chance?)
???????????????????????????????????????????
IMO the system clock and a simple Datediff would do the trick with much less to-do...
...lol...i use a notepad to keep track of my hours (to the nearest 15 minutes...not seconds) but whatever works for ya...
Is an IF...MAYBE...THEN... clause TRUE half of the time?
Using the Date data type would be easier, faster and shorter. You can use the DateDiff function to compare times and Format() to output formatted time dates...
Originally posted by Bean
[B]How is it not an issue? The "job" of the app is to determine how long itself has been running...
If you re-read the original post, you will see that the intent is to measure how long he has been working on the application for billing purposes. Not something that needs great accuracy.
Even if he WAS trying to time the app, then using a methiod which itself interferes with the timing would not be appropriate and DateDiff would be better, as you say. But for what he is doing, the timer is fine. Horses for courses.
Brian
(Fighting with the RightToLeft bugs in VS 2005)
WOW! Had no idea posting such a SIMPLE app would create such an uproar [operative word being 'simple' as stated in original post].
For those concerned about accuracy, please reread the code I used. The system time IS used when measuring elapsed time. The ONLY thing the Timer control is used for in this application is to display a running current time on the form [and yes, there are other ways to do that, using a boolean for example].
Perhaps it was the wording used in my comments at the beginning of the code that confused some of you. Sorry about that. Hope the above clarifies things for you.
I will go back and edit the comment section of the code once I figure out less confusing wording.
By the way, using the DateDiff function can cause some inconsistent 'rounding' problems when trying to determine how many hours, minutes, seconds have elapsed. When I tested it, it was sometimes rounding minutes when only 25 seconds had elapsed and at other times took as long as 42 seconds before the rounding issue arose.
Last edited by doofusboy; Jun 24th, 2003 at 09:23 AM.
Do canibals not eat clowns because they taste funny?
Just to keep everybody happy, I removed the Timer control from the form, modified the code to keep displaying the current time without the timer and modified the starting comments. Everything else still works fine.