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


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


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.

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

      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

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, _
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, _
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!