Made a few changes…
The elapsed time is now saved in raw milliseconds and there’s a Public function to format it the way you want. The function can be called from the Form, Query or Report.
The stopwatch display textbox is now unbound because the display format is no longer required to be saved.
Anyhow, see if that is a little more workable.
A brief edit:
While I’m thinking about it I would like to throw up some of the reasons for saving the raw milliseconds and
not the formatted time.
1. Saving a formatted value is almost like saving a calculated value…generally not good. Actually I think a formatted value
is a calculated value.
2. Saving the raw data allows it to be formatted for display in many different ways.
3. Saving a formatted value, as you have seen, would make it rather difficult to do any calculations on the times.
4. Saving a long instead of xx:xx:xx:xx is more efficient because the former is 32 bits whereas the latter is 88 bits… at least.
5. Not only is storage space increased but also network traffic.
6. When formatting takes place, often ‘data’ is lost; try saving a Name in upper case and then try to work backwards to ‘real’ proper case…virtually impossible.
7. Others are hereby invited to add their own remarks.
As it stands, the above demo will still show 100% CPU usage…not a good sign.
This I believe is the result of simply firing the OnTimer event every 15 milliseconds.
By changing the OnTimer interval to 10,000 it is still just as accurate because the termination of the time interval is done by an event… the click of a button.
I hope this is making some sense…
The timer event, after living with it for a few years, is
not what it seems.
It is
not an interrupt, that’s the very reason it will
not fire while Access is doing something (anything) else.
It seems to be a ‘polled’ timer when Access has nothing better to do and, as such, is forced to the bottom of the priority list of ‘things to do’.
Therefore it will
not slow the Access application that is running it.
If the Access application has something else to do then it will do it.
Internal Edit…
In effect the timer only runs in the ‘white space’ between procedures.
End of internal edit.
Now back to point 5 above…
The timer event will not slow the local application, but it has the
potential to slow
all other applications on a network.
Consider an
idle Access application creating network traffic due to its timer event.
Large amounts of data may be transferred across the network due to the timer event.
Network bandwidth goes through the roof and other users are therefore delayed.
It can happen. In the past (here I go again) they, the excessive network talkers, have been called ‘babblers’… they will not shut up (just like this post, you might think?
)
Anyhow…back to point 7…
End of brief edit:
Regards,
Chris.
