This is a modified version of the CTimer class module from Paul Caton's "cTimer - module-less, IDE safe, machine code timer thunk".
The code has been simplified and the assembly thunk is also enhanced.
There are many class module Timers out there, so why another CTimer?
Because I was not 100% satisfied by either one. :rolleyes:
My most preferred CTimer was from Paul Caton, but were botherd because the 'lElapsedMS' parameter was not reliable as it could go negative.
The only one I know where this problem does not exist is Merri's SelfTimer class module, however there I am bothered as it is event driven and not interface driven. Also the assembly is working with private functions (ordinal address), where I have a dislike on them since I made the expierence that they can go broken in a ActiveX project after a "Binary Compatibility" compile. (means first compile works, but further ones are broken)
The benefit of interface driven "events" is that these are more efficient and it also ensures that the event will be fired. (no 'EventsFrozen' scenario)
Only downside is that this is a "two file" solution, but this is acceptable in my opinion.
So, what is the difference in this CTimer compared to the original from Paul Caton?
The original ITimer interface looks like this:
Whereas my is:
So instead of a ID (Long), there is a Key (String) to identify multiple timers on one Owner.
Important point is that the ElapsedTime parameter is now as 'Currency' and not as 'Long' anymore to be able to represent an unsigned long integer.
So in fact the ElapsedTime value can be from 0 to 4.294.967.295. When it reaches 4.294.967.295 it wraps to 0 again.
This approach ensures that the value is never negative (important) and the timer can run 49.7 days until it wraps to 0.
Example: StartTickCount is -1 (right before GetTickCount wraps internally; unsigned value would be 4,294,967,295) and CurrentTickCount is 101 (after GetTickCount wrapped internally) the result in ElapsedTime (As Currency) will be: 102.
So that means it does not matter where GetTickCount currently is, the ElapsedTime will always work.
Only when the timer ran 49.7 days continuous, then the timer starts from 0 again. (rare case)
The assembly code was modified therefore to get the new results in the ITimer call.
Properties:
ID: Returns an internal identification of a timer. (Default value)
Interval: Returns/sets the number of milliseconds between calls to a timer event.
Functions:
Create(ByVal Owner As ITimer, Optional ByVal Key As String) As Boolean: Creates a new timer.
Terminate() As Boolean: Terminates the current timer.
There is no 'Enabled' property. To determine if the timer is running just check if 'ID' is <> 0.
The 'Interval' must be > 0, as otherwise the 'Create' function will return False and 'ID' remains 0.
To make a reset of the ElapsedTime just set 'Interval' again. (can be changed even if the timer is already created)
In the attachment is also a demo project included.
The code has been simplified and the assembly thunk is also enhanced.
There are many class module Timers out there, so why another CTimer?
Because I was not 100% satisfied by either one. :rolleyes:
My most preferred CTimer was from Paul Caton, but were botherd because the 'lElapsedMS' parameter was not reliable as it could go negative.
The only one I know where this problem does not exist is Merri's SelfTimer class module, however there I am bothered as it is event driven and not interface driven. Also the assembly is working with private functions (ordinal address), where I have a dislike on them since I made the expierence that they can go broken in a ActiveX project after a "Binary Compatibility" compile. (means first compile works, but further ones are broken)
The benefit of interface driven "events" is that these are more efficient and it also ensures that the event will be fired. (no 'EventsFrozen' scenario)
Only downside is that this is a "two file" solution, but this is acceptable in my opinion.
So, what is the difference in this CTimer compared to the original from Paul Caton?
The original ITimer interface looks like this:
Code:
Public Sub Proc(ByVal lElapsedMS As Long, ByVal lTimerID As Long)Code:
Public Sub Timer(ByVal Key As String, ByVal ElapsedTime As Currency)Important point is that the ElapsedTime parameter is now as 'Currency' and not as 'Long' anymore to be able to represent an unsigned long integer.
So in fact the ElapsedTime value can be from 0 to 4.294.967.295. When it reaches 4.294.967.295 it wraps to 0 again.
This approach ensures that the value is never negative (important) and the timer can run 49.7 days until it wraps to 0.
Example: StartTickCount is -1 (right before GetTickCount wraps internally; unsigned value would be 4,294,967,295) and CurrentTickCount is 101 (after GetTickCount wrapped internally) the result in ElapsedTime (As Currency) will be: 102.
So that means it does not matter where GetTickCount currently is, the ElapsedTime will always work.
Only when the timer ran 49.7 days continuous, then the timer starts from 0 again. (rare case)
The assembly code was modified therefore to get the new results in the ITimer call.
Properties:
ID: Returns an internal identification of a timer. (Default value)
Interval: Returns/sets the number of milliseconds between calls to a timer event.
Functions:
Create(ByVal Owner As ITimer, Optional ByVal Key As String) As Boolean: Creates a new timer.
Terminate() As Boolean: Terminates the current timer.
There is no 'Enabled' property. To determine if the timer is running just check if 'ID' is <> 0.
The 'Interval' must be > 0, as otherwise the 'Create' function will return False and 'ID' remains 0.
To make a reset of the ElapsedTime just set 'Interval' again. (can be changed even if the timer is already created)
In the attachment is also a demo project included.