One workaround is to not scan your data into a custom dialog's input field but into a text field directly on the layout or in the layout of a window opened for that purpose. We encountered a bug with FileMaker 10 that resulted in incomplete data being scanned into the input field of a custom dialog. Scanning the data into a hidden field (It's only 2 pixels by 2 pixels in size) worked for us.
Thanks for the suggestion. We will consider that workaround if we get really frustrated and if FM doesn't fix this soon. We have a ton of scripts that prompt users for info (card swipes, etc.) and this would take a fair bit of script rewriting just because of a FM12 "upgrade" issue.
We're noticing that FM12 is much slower at text entry in several areas, perhaps anywhere involving a popup box of any kind plus a few other spots.
Is anyone else noticing slow text entry / lag in FM12?
Filemaker staff, are you working on this as a known issue?
It's particularly frustrating for us as thus far we've only seen slow data entry and a few crashes we'd never seen before FM12 and the new features haven't been of much use to us as yet....
UPDATE: This issue is much more widespread and requires attention.
It looks like many pop-up dialog boxes and windows in FM12 are hampered by the slow keyboard entry response issue.
We've now seen this issue in script editing (try typing text in a comment field or set field calculated result), defining fields, and just about any other window that opens up that isn't a table browse window.
Even more interesting is one that seems to interface with the OS. Choosing Print > Save as PDF and typing in the "Save as" file name area we are seeing slow keyboard response. It's exaggerated and therefore more noticeable when logged in remotely but still quite detectable if you type quickly when connected locally.
One of the most frustrating places this occurs is acknowledging a no-items-found dialog box ("no items match this criteria"). When we type return to acknowledge and "modify find" it takes several seconds to respond. The user often doesn't know if the return key actually was pressed and hits it again, which caches and just performs a second find once the application catches up. If the user wants to cancel the find, it still holds up the program for about five seconds just waiting to acknowledge the escape key. It's a pain and makes us long for Filemaker 11; we're tempted to downgrade.
Filemaker Staff: Will someone please comment to indicate if this is a known issue being worked? If not, do people think this is somehow unique to our installation (which ran fine on FM11) and something we can address or is everyone experiencing this issue??