Version 4

Version 4 - Int Speed 4.vbp

Code changes	This fourth version attempts to fix one problem in the third version, which is the accuracy of the timing results. Instead of using the Time function, this version of the program shows more accurate timings via use of the Windows API function timeGetSystemTime.
Windows API calls WHY?	The reason for using Windows API calls is to accomplish things that are no otherwise easily accomplished in Visual Basic. In this case, we want to get more accurate timing values, and this is the only way to do it. One thing about Windows API calls is that you can easily crash Windows and lock up your computer if the incorrect parameters are passed (or if the Declare statement is incorrect). It is generally a good idea back up your source code files, and "save early, and save often" when trying to use a Windows API function the first time.
Windows API calls HOW?	To call a Windows API routine, you need to declare it in a standard module. In this version of the program, that module is named Time.bas. It contains several items, including the Declare for the function, as well as some Type declarations. There are several ways you can get these declarations for Windows API calls. One that is included with Visual Basic is the Windows API viewer utility. Unfortunately, the text files that it uses contain numerous errors. It is not recommended that you use this as your only source. The best alternative is to buy a copy of Dan Appleman's book "The Visual Basic programmer's guide to the Win 32 API". The newest version is for Visual basic 6.0. It has a fairly complete reference list of most, but not all of the functions that would be of interest to Visual Basic programmers. Another option is to try to find information on the Internet. If you are lucky, someone has already set up a Visual Basic example that actually works properly. I have done the work for you in this sample project.
Time.bas Declares	Here are the declarations needed to use the timeGetSystemTime Windows API routine. Note that the declarations from the API Text Viewer for the MMTIME type were not correct. I got the correct version from one of the Visual Basic courses that I teach. Declare Function timeGetSystemTime Lib "winmm.dll" _ (lpTime As MMTIME, ByVal uSize As Long) As Long Type smpte hour As Byte min As Byte sec As Byte frame As Byte fps As Byte dummy As Byte pad(2) As Byte End Type Type MMTIME wType As Long units As Long 'These were not given by 'the API Viewer application! smtpeVal As smpte songptrpos As Long End Type Dim StartingTime As Long Const TIME_MS = 1
Time.bas VB Wrapper	One thing that is desirable when calling Windows API routines is to have a Visual Basic "wrapper" around the actual API calls. The VB wrapper takes care of the details of communicating with the Windows API routines. The idea is that it will be easier for your VB code to call the VB wrapper rather than the Windows API routines. There are two wrapper routines here. BeginTime simply calls timeGetSystemTime, and stores the starting time in the StartingTime variable. EndTime is a function that also calls timeGetSystemTime. It calculates the elapsed time based on the StartingTime value, and returns the elapsed time to the calling routine. Public Sub BeginTime() Dim mmt As MMTIME Dim TimeValue As Long mmt.wType = TIME_MS TimeValue = timeGetSystemTime(mmt, _ LenB(mmt)) StartingTime = mmt.units End Sub Public Function EndTime() As Single Dim mmt As MMTIME Dim TimeValue As Long mmt.wType = TIME_MS TimeValue = timeGetSystemTime(mmt, _ LenB(mmt)) EndTime = (mmt.units - StartingTime) _ / 1000 End Function
Timing Results	Now we can generate accurate timing results for each variable type separately. I have run some tests onvarious PCs and shown the results in Timing Results.
Outstanding problem	There is one problem remaining, which is getting valid timing numbers when you click the various command buttons multiple times, interrupting numerous other loops that are running. This can be done, but it will be tricky!