hope my English is good enough that you can understand my problem…
I would like to use a xojo program as a serial device.
For example… you have a barcode scanner and a special application. The driver of the barcode scanner creates a “COM5” in windows. Now you can configure the application to communicate with the scanner over COM5…
With the Serial Control in xojo I can communicate with the scanner over its COM5… that is not a problem. But I don’t want to communicate with the scanner… I want to communicate with the application via COMx…
What I would need is XojoApp, that creates his own COMx in Windows and then I configure the application to this COMx and my xojo-app works now as scanner and gives data to the other application.
From the top of my head, yes it is possible. It has been a while since i worked with a com port. IIRC, the com port is determined by the device driver of the external device, and you have to poll com ports to find the right one. Then, you manage the connexion. With special adapter cables, a USB port can be used to communicate with a device that has a serial port. There are two main brands of serial-usb adapter cables. IIRC, FTDI-based cables work better, especially on mac.
If your case actually involves a bar code scanner then almost every one I have ever used will emulate a keyboard. You do not need to fuss with serial communications, drivers or com ports. You simply plug the scanner into the USB port and it emulates a keyboard, sending the scanned bar codes as characters just like a keyboard would. I use bar code scanners extensively in my Xojo Apps.
I also use serial com ports as well, but not for bar codes.
Not in Xojo, you can’t create DLLs. The easiest method would be to use a commercial virtual com port application if its just a single site, you could then pipe COM5 (barcode scanner) to COM6, your app would interface on COM6 and COM7 which would then map to COM8 for the next program to listen, thus making the app think it was talking to the barcoard scanner directly via your app. Or you could try two lots of http://com0com.sourceforge.net/ with your app in the middle.
I have a project that uses barcode scanners, and I hate trying to use them like keyboads. There are many problems we’ve run into with the method. Connecting as a serial device is so much more reliable in my experience with scanners.
The other benefit of using the scanner as a serial device is that your application can process the scanned data without being focused, so it can work in the background. It also reduces the risk of users inadvertently activating shortcuts in other applications or renaming files if your application is not focused.
Then you have much better luck with them then we do! Having barcode scanners act like a keyboard has caused nothing but problems in several of our projects. As soon as I switched them to serial all my problems went away and the apps were rock solid from then on. I’d love to hear your secrets. You going to be at XDC?
I also hate using them as HID keyboards. Mostly because of the keyboard focus issues. I much prefer getting via an independent method such as a serial port or whatever the device supports.
As for secrets, what I did for one client that had to use keyboard emulation card swipes (similar problem to barcodes) is configure the swipes to prepend a Fx function key to the data (via its configuration profile). Then I had that function key act as a shortcut and move focus to the field where I needed the data. And used the carriage return at the end return focus back to the control that previously had the focus (which I saved before moving the focus).
It isn’t perfect but was WAY better than relying on the operator to focus the input correctly.
This was back in VB6 days, not a Xojo project, but the theory is the same.
Interesting. We have an application that processes about 1,500-2,500 bar codes per day on multiple scanning stations for outbound shipments. It then sends the scans to our ERP system to so it can be compared the scans to what was actually ordered. The bar code scanning was the easiest part, but I will say there IS a difference in scanners and we did learn this the hard way. We only use WASP wired scanners which are a bit more expensive but worth it. They work like they should. We did get a hold of some Chinese wireless units that did not work well at all - delayed scanning, sometimes only half the characters, etc. But this was the scanner and we could see this in any application, even notepad just scanning bar codes rapidly would cause issues.
I am not doing anything really special. We just have an input field that captures the scanned data. Once we received a carriage return it looks up the item based on UPC Code and writes a record with the barcode, item, scanning station, box, pallet and exact time. Typical time between scans is 500 ms. We do put the application in a “Scan Mode” that does force focus onto a specific field.
Let me know if you want the model number of the scanner.
I would add that if you cannot depend onhaving control of when or where (as in a textfield) the scan will occur and you simply want it to pass characters regardless of the state of the application you can put the scanner into RS232 mode, connect with USB and it will show up as a serial device and push characters to the DataAvailable event of the serial control.
The WASP WLS9600 comes with a manual that allows you to scan special bar codes that configure the scanner to specific operations; USB, RS232, Keyboard Wedge. It only has one connection - USB, but I believe if you scan the config for RS232 it simply shows up as a COM PORT using the FTDI interface. But I haven’t tried this.
Hm…perhaps the difference is that our users are interacting with the app while a barcode is in progress. Forcing the focus into a specific field causes all sorts of issues: users get really upset when the focus is taken away from the field they were just trying to type in. Even a user trying to set a checkbox can be frustrated with the focus being stolen back to the textfield. But regardless, if we put the barcodes into serial mode there is no problem.
Yes, avoiding keyboard emulation is aways preferable in my book. I was just saying that if you don’t have a choice (such as hardware limitations) that in some cases you can reduce the consequences by configuring a prefix that works as a hot key to force the UI focus. As you note, that has its own side effects. But in some scenarios it can at least mitigate it to a point. (By the same token, I always hated “SendKeys” in VB…)
It all depends on the application. In mine, the user clicks a button or presses the spacebar, which brings up a modal dialog window with a single text field into which the barcode reader acting as a keyboard spits its data. There is no question of “focus” in this case.
I agree, it really depends on the use-case. In our application the user is either scanning bar codes or using the interface, not both, so it works. Your use-case is very similar to ours, but I can see how in Bob’s situation it would need to be treated it as a serial device.
Totally agree. If I could control when the scan occurs I’d have no issues. But it can happen at any time and the user could be editing data. Serial is the only way to go in my case.
Sadly, we have one project where the client does NOT want to force that to happen. I was kind of hoping that you had some solution that would help with that one.