03-05-2007, 03:45 AM
Okay, I don't know why the hell I didn't think of this earlier. It just randomly came to me a while ago. Hope you like it, Verrigan. :wink:
Basically, this wrapper will take all the pros of this system and eliminate most all of the cons (adds slight overhead, but hardly anything to worry about). What you do is make one call to initialize it, which will create an offset value that will allow your program to start at the smallest signed 32-bit value (which is -(2^31)), or a VB Long.
This doesn't let you run your program for an ungodly amount of time like what Verrigan posted does, but it will let your program run for 2 ^ 32 milliseconds (about 50 days). So you have a roll-over time of your program being up for 50 days, not the computer being on for 25 days.
Demo project:
I do a quick -1 on the init up there just in case rounding takes a turn for the worst and creates an overflow. I don't think you'll be sad about loosing 1 millisecond. :wink:
Pros:
- Retain 32-bit timers (not as widely used in MS, but if you use Time Based Modeling you will have a timer for just about everything)
- Based on the application's time running, not the computer's (although still, the 64-bit timer would've probably never rolled over)
Cons:
- Slightly more overhead (about 10% slower, but its so fast as it is in the first place)
To be honest, I can't remember how much MS uses tickcount-based timers (ie timers that count based on the system's tick count, not by "counting down"), but I believe it is quite minimal, so this may not benefit MS greatly, but I'm sure some people will find use for it.
Basically, this wrapper will take all the pros of this system and eliminate most all of the cons (adds slight overhead, but hardly anything to worry about). What you do is make one call to initialize it, which will create an offset value that will allow your program to start at the smallest signed 32-bit value (which is -(2^31)), or a VB Long.
This doesn't let you run your program for an ungodly amount of time like what Verrigan posted does, but it will let your program run for 2 ^ 32 milliseconds (about 50 days). So you have a roll-over time of your program being up for 50 days, not the computer being on for 25 days.
Demo project:
Code:
Private GetSystemTimeOffset As Currency
Private Declare Sub GetSystemTime Lib "KERNEL32.DLL" Alias "GetSystemTimeAsFileTime" (ByRef lpSystemTimeAsFileTime As Currency)
Private Sub InitGetTickCount()
'Get the initial time
GetSystemTime GetSystemTimeOffset
GetSystemTimeOffset = (GetSystemTimeOffset + (2 ^ 31)) -1
End Sub
Private Function GetTickCount() As Long
Dim CurrentTime As Currency
'Return the system time as a long
GetSystemTime CurrentTime
GetTickCount = CurrentTime - GetSystemTimeOffset
End Function
Private Sub Form_Load()
InitGetTickCount
Me.Show
Do
Me.Caption = GetTickCount
DoEvents
Loop While Me.WindowState = 0
Unload Me
End
End SubI do a quick -1 on the init up there just in case rounding takes a turn for the worst and creates an overflow. I don't think you'll be sad about loosing 1 millisecond. :wink:
Pros:
- Retain 32-bit timers (not as widely used in MS, but if you use Time Based Modeling you will have a timer for just about everything)
- Based on the application's time running, not the computer's (although still, the 64-bit timer would've probably never rolled over)
Cons:
- Slightly more overhead (about 10% slower, but its so fast as it is in the first place)
To be honest, I can't remember how much MS uses tickcount-based timers (ie timers that count based on the system's tick count, not by "counting down"), but I believe it is quite minimal, so this may not benefit MS greatly, but I'm sure some people will find use for it.