views:

309

answers:

1

I need to communicate with a bar code scanner connected over a serial port in Microsoft Access. In older versions of Access I was able to use a wrapper around MSCOMM32.ocx that no longer seems to work. I can't use wedge communication because I need to use ACK/NACK which is only supported through the RS232 interface and I need to send messages to the scanner, which is also only supported through the RS232 interface.

Are there any controls in widespread use that support serial communication in Access 2007?

EDIT: In case anyone comes across this, the newest version of MSCOMM32.ocx (I believe dated 3/09) still works fine as of this writing. It is older versions of MSCOMM32.ocx that do not work.

+1  A: 

I can't vouch for the answer, but I can say that Tony Toews is a reliable person, and on this topic, he posted on his blog last year:

An older version of MSCOMM32.OCX has had the "kill bit" flag set.

As Tony says, it's almost always better to rely on Windows APIs than it is to build your app with connections to an ActiveX control. Windows APIs don't really have the versioning problems that ActiveX controls and OCX's do.

David-W-Fenton
Your answer is a comment. The question implies MSCOMM32.OCX is no longer available for use and asks about control availability, not whether APIs can be accessed directly.
bglenn
Using the Windows APIs is a solution to the problem, i.e., that the ActiveX killbit patch breaks this OCX (among others). You might try using a more recent version, but someday, MS might issue a patch that breaks that one, too. The APIs are not going to break unless the version of Windows no longer supports the Win32 API. That looks like a real solution to me -- don't use the method that is easily broken by actions beyond your control.
David-W-Fenton
The question was "Are there any controls in widespread use that support serial communication?" not is there an alternative method to the use of controls. Though irrelevant as well, your point about using Win32 APIs over controls is also ridiculous given the development environment (Access 2007).
bglenn
@bglenn: I think that if you polled Access MVPs and experienced Access developers you'd get an overwhelming majority recommending avoiding add-in controls for things that can be done with Windows APIs. The distribution and long-term support issues with ActiveX controls and the inability of Access to recover well from their failure seem to me to make the preference for APIs over add-in controls indisputable. The point is that you're not asking how to solve your problem so much as you're asking for a resolution to the problem you've created by pre-choosing as solution that is less than optimal.
David-W-Fenton