Reading a virtual COM port

[rede96]

I have a bar code scanner I can set to act as a virtual COM port and I'd like to set up a connection in my DB to the scanner so the DB will pick up any bar codes scanned.

This is my first try and doing anything like this! So was wondering if any kind souls might be able to help me set this up.

I did have a read around the forum but most info was using MSCOmm. I don't have this or at least can't see how to reference it.

Can anyone help please.

 

[CJ_London]

is your scanner connected via a usb port? if so, it acts the same as any input device squeeze the trigger and whatever control has the focus receives the barcode. If not how is it physically connected?

 

[rede96]

is your scanner connected via a usb port? if so, it acts the same as any input device squeeze the trigger and whatever control has the focus receives the barcode. If not how is it physically connected?

Hi, yes it is USB and I already have the scanner working in keyboard mode. But the problem with that is that focus needs to be kept on a specific field in a form at all times or it won't pick up the read.

Hence why I wanted to connect directly via the virtual com port so I could make some code to accept the scanner input in the background.

 

[HiTechCoach]

Hi, yes it is USB and I already have the scanner working in keyboard mode. But the problem with that is that focus needs to be kept on a specific field in a form at all times or it won't pick up the read.

Hence why I wanted to connect directly via the virtual com port so I could make some code to accept the scanner input in the background.

What you described on how it is working is how barcode scanning works on a PC. It is just another type of keyboard. You must first place the cursor where you want the data then type or scan.

I have many clients that scan barcodes into my Access applications. I have never had the need to do what yo(u ask with a (virtual) com port. I use the keyboard input method. I did have to tweak my forms to be able to handle high volume scanning.

I have worked with GPS devices that streamed data to a com port. I was able to read the incoming data stream with Access and VB6. The problem with Access is that while "listing" to the com port it could not do anything else until the "listening" was canceled.

In my experience, If you can't use the keyboard data method then Access is probably not a good platform for the application. Or at least the scanning module. It is possible to create a separate scanning module/application that uses the same Access or SQL Server back end. I have used this method to allow smartphones to work as barcode scanners.

 

[CJ_London]

is the field unbound?

Usual routine is to have a continuous form to trap all readings and/or if there are other fields in the form to set tab stop to no for the other fields and set the form cycle property to all records

On all the barcode readers I've used you can also set the 'click' behaviour to include or otherwise a carriage return

 

[The_Doc_Man]

It might be possible, since this is acting like a keyboard, to have a small database set aside to do one thing - but do it forever - and that is to read the data stream from that COM port. It is possible to do file I/O to an asynchronous port with no timeout. So build TWO unequal front ends for a common back end. The monitoring FE has one form that opens on launch and connects to the COM port with a READ and, as soon as the read is satisfied, you insert a record into a temp table after which you IMMEDIATELY jump back to the READ. If you can open the COM device as a device then you aren't stuck with having the database always be visible and always have focus. That kind of thing CAN run in the background as long as you code the loop correctly.

Put a Timer on this form for, say, 1 minute (60000 milliseconds, because that's the timer unit). Have another table in the BE that contains a single record, control status, that is controlled from the more general FE. You would use this to update the control record to say "Shut Down" or whatever code you want to use to tell it to shut up already. On being given the signal through that shared status table, your listener FE could just close the form and exit/quit.

The general FE is the one that you use to examine data, build reports, etc. but it talks to the same BE as the "listener" FE. Variations on this theme might include having a temp table for data input and you only feed data from the device to the listener table. But when you run the general FE, you can "harvest" the listener table to see what has come in since you last ran the general FE.

 

[rede96]

What you described on how it is working is how barcode scanning works on a PC. It is just another type of keyboard. You must first place the cursor where you want the data then type or scan.

Usual routine is to have a continuous form to trap all readings and/or if there are other fields in the form to set tab stop to no for the other fields and set the form cycle property to all records

On all the barcode readers I've used you can also set the 'click' behaviour to include or otherwise a carriage return

To answer both of those, I already have my scanner connected via USB and set up to keyboard wedge and have a continuous form where data is received. So no problem getting the data into access that way. I've also programmed my scanner with the enter suffix so it moves to the next field in my form as I am scanning multiple bar codes.

So all is good but I can't help but think there must be a better way of handling the scan data that doesn't reply on a field in a form having constant focus. I noticed my scanner has a virtual COM port option so wanted to explore this but just have no idea how to connect to the virtual COM port.

I did have to tweak my forms to be able to handle high volume scanning.

I'd be really interested to know what tweaks you did for high volume scans if you don't mind sharing. Once fully operational I might have that issue.

 

[rede96]

It might be possible, since this is acting like a keyboard, to have a small database set aside to do one thing - but do it forever - and that is to read the data stream from that COM port. It is possible to do file I/O to an asynchronous port with no timeout. So build TWO unequal front ends for a common back end. The monitoring FE has one form that opens on launch and connects to the COM port with a READ and, as soon as the read is satisfied, you insert a record into a temp table after which you IMMEDIATELY jump back to the READ. If you can open the COM device as a device then you aren't stuck with having the database always be visible and always have focus. That kind of thing CAN run in the background as long as you code the loop correctly.

Put a Timer on this form for, say, 1 minute (60000 milliseconds, because that's the timer unit). Have another table in the BE that contains a single record, control status, that is controlled from the more general FE. You would use this to update the control record to say "Shut Down" or whatever code you want to use to tell it to shut up already. On being given the signal through that shared status table, your listener FE could just close the form and exit/quit.

The general FE is the one that you use to examine data, build reports, etc. but it talks to the same BE as the "listener" FE. Variations on this theme might include having a temp table for data input and you only feed data from the device to the listener table. But when you run the general FE, you can "harvest" the listener table to see what has come in since you last ran the general FE.

I basically have two front ends. One to just capture the data and one for doing reports and charts etc. But as mentioned above what I wanted to do is explore a different way of getting the data into the database though connecting via a virtual COM port and not using the keyboard emulation, which is an option my scanner gives. So in essence, I am trying to make a little project that will capture data sent from the scanner via reading the com port and drop it in to the BE.

 

[Uncle Gizmo]

The usual way I approach this sort of problem is to search a vb6 forum I did a quick search and came back with some Leads:-

This is a Google search for:- Microsoft Access VBA MSComm
https://www.google.co.uk/search?q=M....serp..0.5.419...0j35i39k1j0i20k1.YDgrxBeTB0o

https://social.msdn.microsoft.com/F...n-vba-adding-mscomm-to-the-tools?forum=isvvba

https://msdn.microsoft.com/en-us/library/aa259393(v=vs.60).aspx

There's some VB code in the download on this page that you might be able to extract. I'm not sure which version of VB it is..
http://www.developerfusion.com/code/195/mscomm-example/

 

[Uncle Gizmo]

I also found this:-

http://www.taltech.com/winwedge

I don't know how many dollars you've got Handy!!

 

[The_Doc_Man]

If the COM port can be opened as a device using the VBA Open "devicename" For Input As File #1 syntax, you can do a Read Line #1, String and immediately send that string into some staging table to be processed by your other database FE. All you need is the device name to do that, if all it is doing is sending "datastream <CRLF>" through that COM port.

 

[rede96]

I also found this:-

http://www.taltech.com/winwedge

I don't know how many dollars you've got Handy!!

Thanks for the link. The bc wedge looks like it could be a solution, so I'll give it a try. Just wish I had enough vb knowledge to make an app like that myself.

But thanks very much for that. And great instructional videos too!

 

[rede96]

If the COM port can be opened as a device using the VBA Open "devicename" For Input As File #1 syntax, you can do a Read Line #1, String and immediately send that string into some staging table to be processed by your other database FE. All you need is the device name to do that, if all it is doing is sending "datastream <CRLF>" through that COM port.

Thanks for the feedback. Unfortunately my programming skills are fairly basic so not sure I understand what you were getting at, let alone be able to do it. But I'll have a play around when I get time. Thanks.

 

[rede96]

Just an update. I have solved this problem now. One of the reasons I was having so much difficulty is the software app sent with the scanner to program it was well out of date! So it wasn't setting the scanner to output in virtual COM mode.

Once I discovered this and downloaded the up to date version, I was able to use an activeX control to listen to the virtual COM port and pick up any scans made. I just added a bit more code so it would add data to the tables via VBA.

So it works great now.

The link to the activeX control in case anyone is interested is below.

https://www.tec-it.com/en/software/data-acquisition/tconnector/activex/Default.aspx