7 Replies Latest reply on Nov 8, 2010 4:58 PM by tcmeyers

    Possible character buffer problem when using keystroke trigger

    tcmeyers

      Title

      Possible character buffer problem when using keystroke trigger

      Post

      As an aside, today's iPhone FMGo 1.1.2 update appears to run more quickly.

      I have noticed a possible problem with incoming character buffering when using Bluetooth to sub for the onscreen keyboard. The bluetooth device is a barcode scanner, which of course can output characters faster than I can type.

      I've tested the scanner just pumping scans into the iPhone Notes app, and haven't seen any bad scans after many trials. Scanning into FMGo, however, frequently comes up with incorrect scans, either characters are dropped, or surprisingly, some are repeated, either singly or as a small group repeat. I'd say that one out of every 3 or 4 scans are affected. This makes me wonder if there's a problem with character buffering either in FMGo or at the iOS level.

      The Notes app just accepts and displays the scanned text, but in FMGo I'm doing a "Keystroke" script trigger to look for carriage-returns so that a completed scan can be tested for validity, and actions taken. I know that the keystroke script triggers can slow down the acceptance of character streams, because we have a very old eMac with a USB scanner connected to it, and a similar script handles that input... it's slow enough that you can see the characters appear one by one on that old machine. If, on the iPhone, a logjam of characters isn't being handled well then it could cause the symptoms I've seen. Yes, it still happens in FMGo 1.1.2

      Is this a known problem?

      -Troy

        • 1. Re: Possible character buffer problem when using keystroke trigger
          tcmeyers

          Just another comment on this...

          Scanning into a regular FileMaker field (same hosted database) with no Keystroke trigger presents no problem with stream speed. All scans are correct, no dropped or garbled order. It does appear that the Keystroke scripting delay is what causes the problem to crop up.

          -Troy

          • 2. Re: Possible character buffer problem when using keystroke trigger
            tcmeyers

            Another update:

            The identical hosted database and keystroke trigger works just fine on an iPad with FMGo for iPad. To me this either means that the iPad processing speed is so much better than an iPhone 3GS that no buffer logjam occurs, or that the buffering problem "bug", if that's what it is, does not exist in the iPad version of FMGo.

            On the iPhone 3GS the problem is so bad, having to manually select a mangled scan and rescan, sometimes many tiimes, that it's actually faster to type in the barcode. It's pretty unusable. On the iPad it's just great.

            The Scanfob scanner we are using has an intercharacter delay setting, although it's not clear to me if this setting affects the bluetooth pacing (may just be when it's USB connected), but I did try to set it to maximum delay, with no improvement in the iPhone behavior.

            • 3. Re: Possible character buffer problem when using keystroke trigger
              TSGal

              Troy Meyers:

              Thank you for your posts.

              There has been one similar report, where a bar code scanner was connected to the iPad camera connect kit and able to scan books, but this is not supported on the iPhone/iPod touch.  I have sent your information to our Development and Software Quality Assurance (Testing) departments for additional review.  When information becomes available to me, I will let you know.

              TSGal
              FileMaker, Inc.

              • 4. Re: Possible character buffer problem when using keystroke trigger
                TSGal

                Troy Meyers:

                The scripting speed is slower on the iPhone/iPod touch compared to the iPad.  Therefore, using a keystroke trigger might have a timing issue on these slower devices.  That is, read one character, run a script, read the next character, run a script, etc.  One suggestion from our Testing department is to instead use an OnObjectExit trigger once the scanning has completed.

                TSGal
                FileMaker, Inc.

                • 5. Re: Possible character buffer problem when using keystroke trigger
                  tcmeyers

                  TSGal, thanks for the replies.

                  I just tested the iPad with the iPad Camera Connector Kit and a USB scanner. Apparently the USB device outputs characters faster than our Bluetooth scanner, because, using this, the iPad does indeed have a similar character-dropping problem. For example, a barcode that is actually 1T013255JN came in as 1T0135N when scanned into a field with the Keystroke scripting. Similarly, the scans are just fine into a normal field.

                  It seems that the buffering trouble is the same for both FMGo for iPhone/iPod and FMGo for iPad.

                  I'll try the OnObjectExit trigger next. This hadn't occurred to me since we are intending to stay in the same field for additional scans.

                  -Troy

                  • 6. Re: Possible character buffer problem when using keystroke trigger
                    tcmeyers

                    The OnObjectExit method does seem to be a good way to get around the buffering issue, perhaps even the "right way" to accomplish what I needed as well. It's hard to prove a negative, but I haven't been able to get the scans to be corrupted using either the bluetooth scanner on the iPhone or the USB scanner via the Connection Kit on the iPad.

                    It takes a little setting up. These are the steps I took. The field must be configured so for "Go to next object using: Return" so that the received CR from the scanner will attempt to make it exit from the field. This triggers the OnObjectExit script (set up below) on the incoming carriage return. That may not actually have been necessary because of the next step. The field is set to run the OnObjectExit script, in which (aside from testing the validity of the most recent scan) it also appends a ¶ (carriage return) to the field data, since this is actually stripped off by making the field react as "Go to next object using: Return". In addition, by putting a Exit Script [Result: 0] at the end of the OnObjectExit script, the cursor actually does NOT exit the field (which is what I wanted). Interestingly, the relationships to the list of scans in the field do seem to update even though I don't have a Commit in the script.

                    I also added another field and set the tab order on the layout to go to it next, just to confirm that the cursor wasn't just staying in the desired field just because there wasn't another. It did not go into this field which I think means the Exit Script [Result: 0] indeed is what keeps the cursor in the desired field.

                    Thanks, TSGal, for this suggestion that works.

                    I'm going to post another "answer" related to this which maybe should be a different issue. Please tell me if so.

                    • 7. Re: Possible character buffer problem when using keystroke trigger
                      tcmeyers

                      As part of the validation, the script warns if a barcode has already been scanned (or maybe a bar on the wrong kind of object). On the Mac, the script highlights the offending most recent scan in the list, so that all the user needs to do is rescan the correct bar, replacing the duplicated one with no fuss or mousing/keyboarding. This is done using an appropriately calculated Set Selection [Start position: End position] script step.

                      I had noticed that this doesn't work on the iPhone but I seemed to recall that the "differences in FMGo" docs may have said that feature won't work, so I didn't pursue seeing if I could fix it.

                      The testing with the iPad, though, surprised me when I saw that bad scans actually WERE highlighted according to my scripting, so it seems that that script step works in the iPad version of FMGo.

                      I'm hoping that this feature (if it was intended) will also come to the iPhone/iPod version of FMGo.