Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Bar Code Scanning into Edit Line
I am using a bar code scanner as an input device. When I used an edit line as the control to receive the input from the bar code scanner, there was some type of delay between character "keystrokes". I eliminated some overhead by disabling the "CHAR" and "CHANGED" event and saw a great improvement. The only problem now is that if a user scans multiple bar codes quickly in a row the input from the first one will be truncated by the input of the second one coming in.
On all other windows applications that I have the input from the bar code scanner has not had this issue. Any ideas on how I can achieve a synchronous input, where one input cannot interrupt the previous input?
On all other windows applications that I have the input from the bar code scanner has not had this issue. Any ideas on how I can achieve a synchronous input, where one input cannot interrupt the previous input?
Comments
Just so I am clear, you are using a wedge device? That is, one that inputs through the keyboard port?
Sorry, I was speaking in old school tech. This is still functioning as a keyboard input device - it just receives input from the barcode scan rather than a key press.
I have never heard of this happening before. i was surprised you were getting delays. You said you had to disable the CHAR and CHANGED events to speed this up. What were you doing in those events?
So if you bring up Notepad or Word, and scan multiple barcodes you get both barcodes intact? But when you do this in an OI edit line control your first barcode is getting truncated and the second barcode is received entirely? Are you returning a carriage return automatically? Have you tried other OI controls or even just opening an OI code editor and seeing what happens? I am trying to help isolate the condition that creates this problem for you.
You had asked what I was doing in the CHAR and CHANGED events. The only processing going through those events was the code I have for my general promoted event handler that passes the event name to the commuter module for the form.
The problem is greater with the laptop computers that process a little slower than the desktop PCs, of course. The laptops are more of the concern, because they will be used to gather the inventory data, and will have the most chance of the rapid scans causing misreads.
As a fall back measure, I believe I can change the settings on the USB bar code scanner to set a longer delay between scans.
The application was receiving input from an HID interface barcode scanner (where the data from the barcode is entered as if done by keystrokes on a keyboard). I had the barcode entered into an editline, and then that data was processed and put into an edit table in the form. Focus was then put back on the editline to receive more input from the barcode scanner. I found that if I scanned the item multiple times in a row very quickly, some of the scans would be missing some of the first digits of the scanned bar code. In doing more investigation I found that the problem had everything to do with FOCUS. The scanner settings were such that once the barcode information was entered it would add the Enter key as the last digit. This would invoke the LOSTFOCUS event where I put the code to process the data and put it into the edit table and then to put focus back on the editline. The missing digits from the barcode were being lost if they were scanned in that brief moment when Focus moved from the editline to the next control before it was sent back to the editline.
Once I knew that a lack of Focus was the cause of my problem (in more ways than one), I configured a barcode scanner to scan a function key as the last digit instead of the Enter key. I placed an invisible menu item with a corresponding hotkey as the function key, and placed the processing that was previously in my LOSTFOCUS event and it worked great - no more missing digits.
Now I want to take this one step further, and maybe someone can help me figure it out. In reading a blog from Sprezzatura's Edit Table Cookbook, I noticed where they trapped the Enter key using the Windows API message WM_KEYDOWN. I would like to have all the barcode readers continue to use the Enter key at the completion of a scan, so I wanted to see if I could have the application watch for the Enter key to trigger the data processing, but not let it cause the Focus to leave the editline. I successfully have the Enter key trapped using WM_KEYDOWN to look for the VK_RETURN value, but the only problem is that I can't figure out how to cancel the change of Focus from the Editline to the next control. Is there some way to this that I am missing? Can it be accomplished using the Set_WinMsgVal function? (I can't find any documentation about the function but saw in another blog post where they successfully cancelled the deletion of an Edit table row before it occurred.) Any tips would be appreciated!
I am pleased to read that you unearthed the core of your problem. Obviously there was more to the puzzle than what anybody originally understood.
At what point are you setting the focus back to the edit line control? From what I gather, you do not need the focus to get to the edit table - that is just the control next in tab order - correct? Have you tried setting the focus back to the edit line during the LOSTFOCUS event of the edit line itself? I am just curious if that would improve the success rate of capturing all barcode input. Of course, this could create undesirable behavior in your form if the user is supposed to be able to navigate to other controls. There are ways of working around that, but we can discuss those if my suggestion solves the immediate problem.
Do you know of a way that I can programmatically stop the Edit Line from losing focus when the Enter Key is pressed? I already have success in qualifying the event WM_KEYDOWN to listen to the keystrokes in the WINMSG event and identifying the Enter Key, but I need a function that can stop the focus from leaving the Edit Line control before it happens.
Try using the NEXT property to force the edit line to be the next control in its tab order. This prevents the focus from moving away when the user presses Tab or Enter. It will not prevent the user from clicking away. This will prevent the LOSTFOCUS event from even firing. I am assume this is okay with you since you are now trapping activity with the WINMSG event.
Thanks Don!
The system beep (or "ding") is not directly related to the NEXT property. Usually the cause of the ding will be reported in the System Monitor as an error. It can also occur if the engine is busy while a process attempts to execute. You would have to troubleshoot this.
Okay - I can't just let the "ding" go... I did a few simple tests, and I want to see if you can duplicate the same results. I'm finding that whenever the Edit Line control has itself as the value of the NEXT property, it will "ding". You can make a brand new non-databound form and add one Edit Line. Save and test drive the form and when you try to advance out of the Edit Line (hitting Enter key or tab) then you get the "ding". To make sure that it wasn't something in any promoted event code, I even made a new application without any promoted events code. In short, I don't know if there is something I can do about the "ding" or if it is just an OI thing.
You are right. I get the same behavior. I don't think I have ever set the NEXT property of a control to itself. I typically create a small loop of controls that I want to have a tight tab loop (such as all controls on the same page when I don't want the next page to appear just because the user tabbed off of the last control of the current page.)
I did some simple log checking and there are no obvious system errors that are causing the ding. So this is really an OI issue, but I don't know if it is expected or preventable.
So, I may have sent you on a wild goose chase with this. To atone for my error, I will make a peace offering by submitting another idea. :-D
Instead of using an edit line control try using an edit box. This way the Enter key will not cause a LOSTFOCUS event. Instead, it will just create a new line. Your trapping logic should still work and you don't have to fiddle with the NEXT property.
That is an excellent idea and I think it will fit the needs of the application perfectly!