2D Barcode Scan & Unicode Issue.

[NYPoke]

Not really sure where else to put this question, but the Developer threads usually have the most talented FM people.

Quick overview: We are setting up a 2D Bar Code scan for Car Titles, using the AAMVA standards. The 2D Format is PDF417. We are using the Honeywell 4600r reader/scanner.

We use FileMaker 11 Client & Server, v2. Windows Clients & 2003 Server.

After messing around with this for a couple days, I'm pretty close. We had to turn on the Honeywell Windows Mode Control & ASCII Mode. If not on, the data is just mushed up. No line feeds/carriage returns & not all fixed length data.

However, when we do this, FileMaker kicks us out of the edit field on the 2nd character.

First character is "@" (Decimal 64). Second is a line feed (Decimal 10). The third is supposed to be a Record Separator (Decimal 28), but I don't know if it actually gets transmitted.

With Windows/ASCII Mode turned off, FileMaker Text Fields accept the data. However, being unformatted, I can't use it.

I have tried intercepting the data with OnObjectKeystroke (& most other events), with no luck. I can stop FileMaker from exiting the field, but I lose some of the data (slowing down the scanner didn't help).

We can scan to NotePad & Paste it in FileMaker, but that isn't a very good approach for our users.

I suspect this is a Unicode/ASCII issue, but I've exhausted every option I can find with both FileMaker & Honeywell. Wondering if anybody else has encountered a similar problem.

[fseipel]

It sounds like you are receiving the equivalent character to ENTER on the numeric keypad, so the field loses focus? Can you reconfigure the scanner so it sends a carriage return instead? Alternately, can you set up a script trigger to go to the next field so no characters are lost when it scans ENTER? Or set up a script trigger to reformat the data when not in ASCII mode? Or buy another serial/bluetooth/keyboard wedge program that can handle this translation?

If none of these solutions are acceptable, then you can use a webviewer, 360 Works scriptmaster, or a short VBSCRIPT, to allow text input that won't choke on the ENTER key. ScriptMaster would work nicely for this. See URL for an example of single character input. In this case, SM would read the input, then pass it back to FM, and the FM script would populate the field(s). This may be a good quick & dirty solution.

[NYPoke]

Thank you. The script triggers just aren't working, so far anyway. By the time the trigger hits, the damage is pretty much done.

I have tried the Carriage Return thing on the Scanner. However, I will revisit it. I could have done it wrong.

In normal Data Entry, Enter just goes to the next line, but I've written enough data transfer code in the past to never assume.

If this doesn't work, I'll take a look at your other suggestions.

[RodSierra]

Click on the input field in layout mode and under behavior there are 3 check boxes that move to the next field, tab, enter, and return. Click these on or off depending on what you require as the last character received from the scanner to send it to the next field, or just leave all off.

[NYPoke]

Rod, Thanks.

Not sure how I overlooked that. I had been messing around with the Input Methods (Direct, Indirect, ...).

I was excited for a minute. This does change things a bit, but I still can't get a good read. If I disable/enable these settings, I either get the data jumping to different fields or just exiting the record. Can't keep focus on my text field.

Still, it does confirm this is the issue (Enter). See what I can do with the information.

[fseipel]

Rod, that is a much simpler fix to this problem than external input!

Typically what I've seen for barcodes is a special input layout. In this case, it would be populated with global fields. If the input had 5 lines of data you would have 6 fields. You can then set up a script trigger that acts when they enter the 6th field (OnObjectEnter). That script, would then create a new record in the appropriate table, and populate the field(s) with values from the globals, then return to the barcode input layout and go to the first field. In this case, if it all needed to go into one field you'd set field = field1 & "P" & field2 & "P" & etc where P=return or paragraph symbol.

It may also be possible to use a key reassignment program to re-assign the ENTER key to RETURN. The question is whether these would work through the scanner keyboard wedge (i.e. whether it sends keycodes). See http://vim.wikia.com/wiki/Map_caps_lock_to_escape_in_Windows

If the device simulates a serial device, you may want to use a more sophisticated keyboard wedge like serialmagic http://www.serialio.com/products/SerialMagic/index.php -- many of these will allow you to remap keys, even if scanner does not.

[RodSierra]

If it consistently wants to go to a second field, why not just set up another field for that portion of the data, set up your move to next field and let it put the rest there,then merge them later. This perhaps may be the original intent of the way the scan code was set up. We set up all our internal scanners for factory use with tab as the terminating character. This keeps our input layouts standardized, as if a field cannot be scanned due to readability, the operators are uniformly trained to move to the next field via the tab key.

Oh, and sometimes your tab order settings can get in the way of what you intended to don't forget to play with those also.

Edited September 17, 2010 by Guest

[NYPoke]

Well, I think ya'll are right, for the most part. What I found was that the standard CR & LF (10 & 13) never get to the Script Triggers, as Keystrokes. FileMaker is intercepting them, whether I check the Tab/Enter/Return buttons or not.

The number of fields is somewhat in flux though. We have different formats (Titles, Registrations, Drivers Licenses) & different states. While the general format is the same, the CR/LF seems to differentiate, state by state.

The multi-field solution is kind of ugly but might be the only solution. I'm just not sure how consistent it is. Testing will tell.

Only other solution I know is to change the Scanner to use some off-beat value for CR/LF. Given that we are sending these to our offices, I'm trying to reduce how much "programming" goes into the reader itself. So, this isn't the best option.

BTW, I neglected to say that this reader is uses USB, not the keyboard wedge. Not sure how much that matters, but it might.

I was thinking of the multi-field approach but hadn't got around the global intermediate step. I'll give it a try next week. That would beat the other options, at this point.

Edited September 17, 2010 by Guest

[NYPoke]

Well, this just isn't working. This method is breaking up the records but not the lines.

Getting 3 records, with all that data except the Line Feeds, which means I can't parse it.

Should be getting about 20 lines.

Will look at the scanner further & see if I can adjust it.

The data format calls for a Data Element Separator (in this case 13 - Line Feed) and a Record Separator (28, which I think is standard).

I've tried both 10 & 13 for the first one. No matter what, FileMaker intercepts it before I can get the data.

Well, thanks all for the help. If I figure it out, I'll update.

[NYPoke]

Oh my goodness, I got it working. This is kind of messed up, but I get paid to handle messed up stuff.

My missing Line Feed was not that at all. It was a decimal 31, not a 10. The control characters are 31 & under, with 32 being a blank.

I've never seen it or used it before, but it is defined as CNTR-Y. Sounds familiar, unix based maybe?

Anyway, after tracking the Trigger Keystrokes under 32, it showed up. I'm now catching it & putting a FileMaker end-of-line marker in my field.

I'm catching the 13 & returning false, to keep it from going to a new field...only need one data entry field.

To quote Homer Simpson: Wooo Hooo.

I'll put a copy of the script here next week, but it is pretty simple.

I'm sure this is a scanner issue or the DMV. Don't care a the moment though. Just relieved that it is working...