0

I've dropped the VB6 MSCOMM32.OCX (Microsoft Comm Control 6.0 (SP6)) on to a VBA form. I had to apply a Microsoft Security Update KB926857 to VB6 to get the control to drop on the form because a Windows Update set a kill bit on the older version.

When I look at the object's events in VBA I do not have "OnComm" available. I can get it in VB6 by double clicking its icon (a phone) but not in VBA. Importing it in Delphi shows OnComm as the only event handler.

I know the control is registered properly and licensed.

I've done it a couple of years ago with the older control, but has anybody done this lately?

Available Events: OnEnter, OnExit, OnGetFocus, OnLostFocus & OnUpdated

Tony Toews
  • 7,850
  • 1
  • 22
  • 27
Rich Shealer
  • 3,362
  • 1
  • 34
  • 59
  • Try creating the event manually and see if it fires. Private Sub MyComm_OnComm() I'm using it in Access 2007 without any issue. – HK1 Mar 10 '11 at 13:08
  • Why do you think dropping a non-Access ActiveX control on an Access form is a good idea? You'll no doubt have no end of headaches from this. What are you trying to use it for? – David-W-Fenton Mar 12 '11 at 01:44
  • It accepts data from a hand held bar code scanner over the serial port. I do not like to use the keyboard wedge style because the operator must have the cursor on a specific input box. With serial the focus can be anywhere. Additionally the main application was already written in access, I added scanning functionality. – Rich Shealer Mar 14 '11 at 16:12
  • I've added barcode functionality to existing Access databases. The keyboard wedge method was no issue at all, particularly having the focus on the right field. I'm not sure I understand why this would be a problem. – David-W-Fenton Mar 15 '11 at 21:12
  • When scanning in keyboard wedge mode the user must have the cursor in the field you want the data to go. When I get the scan in serial mode the evnt occurs and I can clear the form, break the data apart and place it in the proper fields. Nice and clean. They app doesn't even need to have the focus and it still goes to the correct place. – Rich Shealer Mar 16 '11 at 20:28
  • Yet, here you are with this problem, which would be entirely absent with the keyboard wedge solution (you could easily scan to a buffer field and parse the data from there -- there are any numbers of ways to skin that cat). – David-W-Fenton Mar 17 '11 at 04:20
  • It was a problem before I figured out what it needed and posted a solution. It's not a problem anymore. The app was deployed last week and was succesfully used for its purpose. – Rich Shealer Mar 17 '11 at 12:40

1 Answers1

0

I discovered independently that HK1's suggestion was correct. I created an event handler that looked like this

Private Sub MSComm1_OnComm()

Nothing needed to be done to the object properties to link it to the routine.

In the form load event I placed an MSCOMM1.PortOpen = True. I scanned a bar code and presto it worked.

Why this is treaded differently than other events I do not know and how/where it is documented is a mystery.

This Microsoft site has helpful information on handling the data properly and is what I used for the test.

http://support.microsoft.com/kb/194922
Rich Shealer
  • 3,362
  • 1
  • 34
  • 59
  • The events of non-native controls have always been handled differently by the VBA IDE, particularly when they've not been written specifically to be compatible with Access. This should be yet another clue that you might consider whether or not it's a good idea to use the control. – David-W-Fenton Mar 13 '11 at 20:59