1 2 3 Previous Next 39 Replies Latest reply on May 18, 2015 8:51 AM by TSGal

    Character order scrambled in input from Bluetooth scanner, field with script trigger

    tcmeyers

      Summary

      Character order scrambled in input from Bluetooth scanner, field with script trigger

      Product

      FileMaker Go

      Version

      FMGo 13.0.5

      Operating system version

      iOS 8.0.2

      Description of the issue

      Scanning barcodes using a Bluetooth scanner yields scrambled character order in the field - when the field has a OnObjectExit script and the field is set to Go To Next Object using Return.

      To check if the problem is the Bluetooth scanner or just iOS 8, multiple scans were done into the Notes app, no scrambling.

      Additionally, scans were done into FMServer_Sample, the Project layout, Description field (I presume this is a simple field with no triggers) and the scans were not garbled.

      Scanning into the field that has the OnObjectExit script, however, almost never gets the scan entered correctly, multiple tries must be done before the scan code just happens to make it OK.

      Manually typing into the field, or using the FM Go device-camera barcode capture DOES work, the scan strings are not scrambled. It would appear that it only occurs when the data is coming via Bluetooth.

      Steps to reproduce the problem

      Create a field for FM Go use, and put a OnObjectExit script on it. Set the field so that Return will exit the field.

      Put the cursor into the field and scan using a Bluetooth scanner which is programmed to output a Return character at the end of scan data.

      Observe that characters that came from the scanner are all there, but in a different order than they should be. Sometimes there is even a character in the field AFTER the Return character.

      Expected result

      Expecting single-line field entries such as these:

      1T017628XI

      1T02878SQ

      1T025683ZN

      1T025569DX

      1T025281OZ

      1T025309NX

      1T025574DS

      ...which are correct barcode scans with error checking

      Actual result

      Bad results such as these:

      1T017628XI may show up as:
      1T017268XI or
      1T01762X8I or
      1T016728XI
      ...on repeated attempts

      OR EVEN, occasionally a character might be reported as if after the Return character so that:
      1T025281OZ might show up as:

      1T02528O1
      Z

      as one entry with two lines.

      Exact text of any error message(s) that appear

      No error message other than our own which reports that the scan is not a valid number.

      Configuration information

      observed on iPhone 4s and iPad models MC989LL/A

      Workaround

      No workaround. We need to use the Bluetooth scanner for high speed multiple barcode reading, and while the iDevice camera barcode scan is handy for occasional single scans, it is much too slow for our use in this application. We need reliable fast Bluetooth entry.

        • 1. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
          philmodjunk

          If you scan multiple items into a single field with no script triggers, does the data appear correct, (but run together) in the field?

          If that works, it might suggest a work around where you make multiple scans into a global text field and then tap a button that parses the scanned data out of the field and processes each scanned barcode in turn instead of trying to process it one scanned item at a time before the next item is scanned.

          • 2. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
            tcmeyers

             

             

            Phil,

            Thank you for the reply. Yes, scanning into a field with no OnObjectExit script trigger and without Go To Next Object using Return set up does produce a list of scans (one on each line) that are correct, not character-order-jumbled. It actually even works (and we've been using in another procedure) to have a script set up that verifies each scan as added to the list. I've been trying to figure out why that one is OK and the problematic one not. It just seems like a character stream buffer is messed up.

            Unfortunately, the problematic one can't be done as a series of scans parsed as a group as you suggested, because in this application we need to do one scan, then touch one of a few buttons to record data about the scanned items. So, it should be scan, touch, scan, touch, scan, touch -- not scan, scan, scan and then try to get the right touches for the right item.

            Have you been able to reproduce the problem?

            Troy

            • 3. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
              philmodjunk

              I don't have your hardware. I've just had some experience with scanning--using a USB scanner in Pro and InsertFromDevice in Go and have dealt with some issues with scanning by others and it occurred to me that your blue tooth scanner might not be waiting long enough between scans to keep it from jumbling the input on you. My first attempt at using a USB scanner was scanning text into the input field of a custom dialog and I discovered that I couldn't trust the results as some of the input was being dropped. Your issue is different, of course.

              If you need to do a scan followed by tapping a control, why do you need an OnObjectExit trigger? Why not set it up so that tapping the control does everything that the OnObjectExit trigger does as well as the additional processing that you want done with this "tap" in your current design?

              • 4. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                tcmeyers

                Phil,

                The reason is that the choices given to tap after a scan depend on what was scanned, the choices vary greatly. Also, it's much preferable to know right away if the scan is incorrect (the scan validation is done as part of the OnObjectExit) rather than to have to wait 'til after a choice is made on the touch-buttons, so that the hand holding the scanner is still well positioned to get the barcode. (These are barcodes on plant tags in a greenhouse, and barcodes on flasks on cleanroom racks in a lab.)

                I thought it might be a speed-of-input issue too, but as you said, it's not just dropping characters, it's getting them out of order. It makes me think that there is some sort of software buffer for the bluetooth data that is goofing up the in and out pointers.

                I feel this is a serious problem, and I'll do whatever it takes to help you reproduce it. FMGo is supposed to be a serious app for business applications, and mis-scanning is a huge time-waster. I have to think that lots of companies are using Opticon OPN-2002 and similar scanners for volume input to iDevices.

                Troy

                • 5. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                  tcmeyers

                  Phil,

                  I should say that I appreciate you trying to find a work-around. My goal in reporting it here is rather to pinpoint the problem so that FMI is aware of it and can work on a fix.

                  Troy

                  • 6. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                    philmodjunk

                    Please note that I do not work for FileMaker, I'm a fellow user of the product. The person you need to "help pinpoint the problem" will be a TS person such as TSshark, TSfalcon or TSGal.

                    I just saw a possible work around that looked worth suggesting and the fact that you can scan multiple codes cleanly into a single field is a significant detail the TS personnel can use in trying to figure out why this isn't working.

                    In that same vein, you might play with your script by trying various simplified options that only do part of the total scripted task--not as a work around but as a diagnostic test here. The fact that characters are appearing out of order has me wondering what kind of glitch might be failing to put the focus (cursor) in the correct cursor position within the field.

                    • 7. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                      tcmeyers

                      Thanks, Phil. I've always wondered what your "role" was. I appreciate your help here and in the past.

                      I will try to see what might be the difference in the scripting, see what "disabling" specific steps might produce.

                      As an aside, I mentioned before that sometimes one or two characters come AFTER the Return character causes a field-exit. I need to wrap my head around that, because the effect it produces is so weird: when the scan does that, the field is exited at the Return, and the OnObjectExit detects the invalid scan and (as part of trying to streamline re-scan) it highlights the bad scan in the field so that the next input will replace it... and once that script releases control, the highlighted text displays very, very briefly, only to be replaced by the character (or in some cases a couple of characters) that went missing before the Return character. And that character is not highlighted, it's as if it were the first character in the next scan with the insertion point blinking after it.

                      Troy

                      • 8. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                        philmodjunk

                        Back when My Known Bugs List became a viable resource, modman signed me up as "community leader". That gives me a higher level of access permissions and the freedom to include a "signature line" with a link to my web site, but that's about it.

                        Is OnObjectExit the only script trigger involved here?

                        With USB scanners in FileMaker Pro, there's often a "keystroke" trigger also in place--some set ups use it on the layout to put the focus into the correct field for the scan, others actually use it to process the scanned data character by character--not what I'd recommend. Since the blue tooth scanner probably isn't emulating keyboard input (or is it?) like happens with the USB interface, I don't know if this is a possible issue or not.

                        Which raises a new question: How do you put the focus into this field before the scan enters data? I have an idea that might be worth exploring if you are interested, that will depend on how you set that initial focus as to whether it is a possibility.

                        • 9. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                          TSGal

                          Troy Meyers:

                          Thank you for your posts.

                          I do not have a BlueTooth scanner to test.  However, since it works properly in one file but not another, there is a small factor that hasn't yet been discovered.  To get around this issue, consider inserting the barcode into a Container field (for a permanent record), and then user Insert From Device [Bar Code] and specify the Container field.  The result can then be put into a Text field without the reordering of characters, and the Text can then be analyzed.

                          Also consider talking to Opticon about any potential issues with iOS 8.  They may also have a workaround.

                          Please keep me updated with any progress as others may also encounter this issue.

                          TSGal
                          FileMaker, Inc.

                          • 10. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                            tcmeyers

                            TSGal,

                            Thank you for the reply!

                            Just to clarify, you said "since it works properly in one file but not another" it actually is the same file, same table, different field (though both globals) and different layout. And different handler scripts. I hope to find what I might change in the OnObjectExit script for the offending field, but haven't fully tried that yet.

                            I have just purchased an additional OPN-2002 Bluetooth scanner to send to you so that you can try to reproduce the problem. How can we make arrangements to get it to you?

                            I've tried to make contact with Opticon regarding any known problems with iOS 8. I haven't had a response from them yet. (If only they had an output-character-pacing adjustment I bet that'd work. When using a Bluetooth keyboard I can't type fast enough to duplicate the problem.)

                            I don't have an iPad or iPhone that still has iOS 7 though I'm hunting for one. Tomorrow I believe I'll have my hands on an iPhone 6 and I can see if that fixes the problem (faster hardware=no more buffer trouble?) and that might be a clue. We are only using iPhone 4Ss and iPad MC989LL/As (not the most recent version, I think it's the first with the camera).

                            I just did a test where I used the same barcoded tag to scan into the problematic field on the same iPhone, but first under FMGo 12 then under FMGo 13. The file is hosted by FMS, so is remote (as is our entire application).

                            Under FMGo 12, I was surprised to find a fairly high error scan rate. I had recalled having to do rescans on occasion, but I had attributed it to dirty barcodes. Using 50 scans of the same barcode, it scanned properly 36 times and incorrectly 14 times. In all cases the mis-scan was exhibited by one missing character, not always the same one, except once there were 2 missing characters. This makes me think that the buffer problem, if that's what it is, has existed for a while and it just wasn't bad enough to be a huge inconvenience. It is, for whatever reason the bad scans are, the reason that we had scripted it to check each scan an vibrate the phone on bad ones.

                            Under FMGo 13 it is so significantly worse that it's unusable. Same tag scanned 50 times yielded 8 correct scans and 42 bad scans. I hadn't noticed this before, but the error scans are not just transpositions, there are some where there are dropped characters as well. To show the kinds of errors, here are some that I recorded. This list will be similar to what I reported in my first post. I've attached a photo of the tag so that you can see what sort of thing we are working with.

                            The barcode should come in as: 1T020355WL. Here are samples of bad data that ends up in the field...

                            1T01T200355WL
                            1T020535W
                            1T02055WL
                            1T023055WL
                            1T025035WL
                            1T020355W (and then the L coming AFTER the Return, after the OnObjectExit script runs)
                            1T01T20055W (and then the L coming AFTER the Return, after the OnObjectExit script runs)
                            1T020535WL
                            1T00355WL
                            1T02055W (and then the L coming AFTER the Return
                            , after the OnObjectExit script runs)
                            1T020355 (and then WL coming AFTER the Return
                            , after the OnObjectExit script runs)
                            1T02035W5
                             (and then the L coming AFTER the Return, after the OnObjectExit script runs)

                            I probably didn't record all of the unique results. Most of the above happened more than once. Note that there are dropped character, duplicated characters, transposed (sometimes more than one) characters, and the whackiest of all, character or characters transposed to after the Return character, so showing up after the OnObjectExit script has run.

                            Regarding the using of the iPhone/iPad camera to capture the barcode, we have been using that all along (since it was first offered) to get around this trouble. It works fine, other than the fact it is so slow to do the capture. It's too slow to be acceptable for this particular task, but we've been having to use it, or to manually type in the code, since the Bluetooth input is scrambled.


                            Troy

                             

                            • 11. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                              TSGal

                              Troy Meyers:

                              Thank you for the additional information.

                              Before sending in the scanner, are you able to change the intercharacter delay?  If so, increase the delay.

                              Performing a browser search, I found the general Opticon Universal Menu Book at:

                              http://www.opticonusa.com/pdf/Manuals/Universal_Menu_Book.pdf

                              U-19 has the settings for the intercharacter delay.  Let me know if this is applicable.

                              TSGal
                              FileMaker, Inc.

                              • 12. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                                tcmeyers

                                TSGal,

                                Unfortunately, we had tried this early on, and I've just verified that it still does not solve the problem. I don't have a way of actually measuring the speed, but it does not appear that it affects the Bluetooth transmission rate at all, as best as I can tell by observing characters appearing in a simple text field. It is labeled as being applicable to USB, and there is a separate set labeled as being applicable to RS-232. I think the bottom line is that this one does not alter the Bluetooth behavior, and I wasn't able to find one for inter character delay for Bluetooth. In any case, the scans do still get scrambled.

                                Before misinformation causes more confusion, I want to correct two bad-scan reports from my last message. I reported:
                                1T01T200355WL
                                and
                                1T01T20055W (and then the L coming AFTER the Return)
                                ...those look particularly odd, but actually are the result of the hander script; if the script detects that the tag number does NOT start with "1T0" which is the expected prefix in this instance, it is added before the scan is tested. The purpose is to allow the user to finger-type (on the iDevice screen keyboard) the short-version of the tag number, omitting the 1T0 prefix, allowing faster entry. You can see the on the photo of the barcode the text version printed under the bars shows what the short form would be. Anyway, the reason these two came up with the prefix added is because the scan placed in the field began with 1T2 in both cases, because the first 0 character was dropped. So, they still were bad scans, but the buffering issue was NOT causing "1T02..." to come out as "1T01T2...", only as "1T2...".

                                To ensure that this auto-prefixing wasn't causing all of the trouble, I "disabled" that portion of the OnObjectExit script. I verified that it no longer added the prefix by finger-typing a short form (which wasn't auto-prefixed, and was thus rejected as a bad tag number), and then checked to see if the Bluetooth scanning trouble was cured... it was not.

                                Troy

                                • 13. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                                  tcmeyers

                                  TSGal,

                                  The new scanner is all configured and ready to send to you. I've verified that it experiences the same problem.

                                  Troy

                                  • 14. Re: Character order scrambled in input from Bluetooth scanner, field with script trigger
                                    tcmeyers

                                    TSGal-

                                    Test results from the iPhone 6 I was able to borrow. It turns out this phone has iOS 8.0 (not 8.0.2) and had the older FMGo 13.0.4, which I tried first, then updated to FMGo 13.0.5 -- with very interesting results.

                                    iPhone 6, iOS 8.0, FMGo 13.0.4:
                                    50-scan test of one barcode as done before (actually with the scanner that is to go to you):
                                    46 good scans (!!!) and 4 bad scans, all of which were just single-character omissions.

                                    iPhone 6, iOS 8.0, FMGo 13.0.5:
                                    Same 50-scan test:
                                    21 good scans, and 29 bad scans, none of those were omissions but were various transpositions.

                                    Surprising stuff.

                                    Tomorrow I'll see if I can try it again with the same iPhone 6 but updated to iOS 8.0.2

                                    Troy

                                     

                                    1 2 3 Previous Next