Databases - MS Access ActiveX Components

Microsoft sort of suggests that you can extend your applications by using ActiveX (ocx) components. Well, I tried to do this by using MSComm32.ocx - the ComPort interface component.

Basically, it worked perfectly on my machine, but did not work on other machines where it was not installed.

This is what I learned.

Using It

Before you can use a control it should be Registered and Referenced. The following menu selections are applicable.

Tools / ActiveX Controls... / 
     Microsoft Communications Control, version 6.0
Tools / References... / Microsoft Comm Control 6.0
Insert / ActiveX Control... / 
     Microsoft Communications Control, version 6.0

Getting data is a bit flakey. You don't use the events in the property editor - instead use the _OnComm event. However, I am reading a 12-byte barcode and _OnComm only returns a few bytes at a time. (The exact number is not predictable.) As a result, you need to set a timer when the first byte is received and reset it each time additional bytes are received. When it eventually times out, the complete barcode has been received. (Well, I think this is kludgey.)

Note:

Tools / References... is not displayed if a form is the active sub-window. Click on a code window and the option will be available.

Packages

Microsoft development software distributes code and ActiveX components using packages. In order to know what to do, ActiveX components are supplied as 3 files

The ocx file - this is the main executable
A dep file - Dependency file for setup wizards. A special ini type file which tells the package builder which additional files are needed in the package.
An inf file - this was not on my system, but it was in the associated cab file

MSComm32.dep is especially interesting - you should read it.

Unfortunately, I could not figure out how to use either MS Access or Visual C++ to create a package - Basically, I was not able to locate the package builder add-in.

The RegMon Trace

Well, eventually I gave up trying to discover how to distribute the module and, instead, I used RegMon to discover what MS Access needs in order to use the component.

Opening MS Access produced no resistry hits that are related to ActiveX components. This is good.

Opening a form that already contains MSComm32.ocx produced 765 hits. The following are significant.

QueryValueEx
 HKCR\CLSID\{648A5600-2C6E-101B-82B6-000000000014}\InprocServer32
    "C:\WIN98\SYSTEM\MSCOMM32.OCX"	

QueryValue
 HKCR\Licenses\4250E830-6AC2-11cf-8ADB-00AA00C00905\(Default)
    (I've elected not to show this 36 character value)

QueryValue
 HKCR\CLSID\{648A5600-2C6E-101B-82B6-000000000014}\ProgID\(Default)
    "MSCOMMLib.MSComm.1"	

QueryValue
 HKCR\TypeLib\{648A5603-2C6E-101B-82B6-000000000014}\1.1\0\win32\(Default)
    "C:\WIN98\SYSTEM\MSCOMM32.OCX"	

QueryValueEx
 HKLM\System\CurrentControlSet\Services\Class\Ports\0001\PORTDRIVER
    "serial.vxd"

Placing the form in edit mode and/or showing the properties of the control hit the same CLSID and TypeLib keys, except not as many times.

Notice that the version 1.1 is called in the TypeLib. Though this is stored in the CLSID, that value was never read. Apparently this is also stored in the form.

Also note that attempts were made to read 4 values that were not found.

Warning

I was never able to get satisfactory performance from MSComm32.ocx on any machine except the one where Visual C++ was loaded. The rest basically failed to recognize the component because of Microsoft's copy protection. I have a completely legal version of the software which I am not able to use.

In addition, some versions of MSComm32.ocx leak memory.

WinAPI

I also tried to write my own ComPort code by calling the Windows API. This was a complete failure because MS Access 97 does not have a way to implement callbacks. (There is no way to pass the address of a subroutine as a parameter.)

VisualBasic 5 introduces the "AddressOf" operator to get function addresses for Windows API callbacks. Unfortunately, that operator is not implemented in MS Access 97.

I did find code (a hack using undocumented VBA DLL API calls) which was supposed to return the address of a function. However, all I got was errors and the returned address was always null (zero). (The author developed the code for MS Excel and suggested that it should work with MS Access. Several references did suggest using it with MS Access. However, I never got it to work.) (Here is part of an application using the code.)

Author: Robert Clemenzi - clemenzi@cpcug.org