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.
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.
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.
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, 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.
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.
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.