I have been looking at these API calls:
the function GetTickCount
the pair of functions
QueryPerformanceFrequency
QueryPerformanceCounter
and this set of functions
timeBeginPeriod
timeGetTime
timeEndPeriod
All of these are missing the ability to reset the time to 0. The timeBeginPeriod doesn't do what it sounds like. It doesn't reset the timer to 0. Instead it simply initializes the timer with a certain level of precision (use 1 for highest precision, forcing it to have a precision no worse than 1 millisecond). In all cases, they get the time (with varying levels of precision, depending on which API function you are using) from the hardware clock chip in the PC, which records the amount of time since the PC was last powered on. None of these API calls give you the ability to reset the internal hardware clock.
A simple workaround is to subtract the current clock value from an earlier one to calculate the time elapsed since then. But that has a problem. The moment you go from &h7FFFFFFF to &h80000000, you are going to have a problem, because VB6 uses signed values only. Even if you handle the numbers as Currency data type (CopyMemory from a Long to a Currency, and then multiply by 10000) you still are going to have a problem on the tick that it goes from 0xFFFFFFFF back to 0x00000000. If you set the initial value when the time is 0xFFFFFFF0, in only 16 milliseconds it will jump back to 0x00000000, messing up anything that depended on your timer working properly (such as selecting a frame to display from a list of loaded frames, based on the timer's current tick count, in a video player for example).
the function GetTickCount
the pair of functions
QueryPerformanceFrequency
QueryPerformanceCounter
and this set of functions
timeBeginPeriod
timeGetTime
timeEndPeriod
All of these are missing the ability to reset the time to 0. The timeBeginPeriod doesn't do what it sounds like. It doesn't reset the timer to 0. Instead it simply initializes the timer with a certain level of precision (use 1 for highest precision, forcing it to have a precision no worse than 1 millisecond). In all cases, they get the time (with varying levels of precision, depending on which API function you are using) from the hardware clock chip in the PC, which records the amount of time since the PC was last powered on. None of these API calls give you the ability to reset the internal hardware clock.
A simple workaround is to subtract the current clock value from an earlier one to calculate the time elapsed since then. But that has a problem. The moment you go from &h7FFFFFFF to &h80000000, you are going to have a problem, because VB6 uses signed values only. Even if you handle the numbers as Currency data type (CopyMemory from a Long to a Currency, and then multiply by 10000) you still are going to have a problem on the tick that it goes from 0xFFFFFFFF back to 0x00000000. If you set the initial value when the time is 0xFFFFFFF0, in only 16 milliseconds it will jump back to 0x00000000, messing up anything that depended on your timer working properly (such as selecting a frame to display from a list of loaded frames, based on the timer's current tick count, in a video player for example).
