Thank you for your post.
I am unable to replicate the problem with a simple database. When I enter text in the field, I tap a button to switch to another Layout, and it works without incident. Can you provide any more information? Or, in case there is something in your file that FileMaker Go is not liking, can you send in a clone of your file? If so, check your Inbox at the top of this page for instructions where to send the file.
I'm e-mailing you a copy of the file I was working with.
I concur with Matt. There is a problem with entering text as input to a Custom Dialog. If you don't dismiss the keyboard, FileMaker Go 1.2 just quits.
Matt Spencer and Jade:
I was finally able to replicate the problem on an iPad. However, subsequent attempts have been successful. I was never able to replicate the problem on an iPHone or iPod touch.
In either case, I have forwarded your posts (and my initial finding and the YouTube video Matt Spencer emailed to me) to our Development and Product Management departments for review and confirmation. I will continue to keep you posted.
I got the same problem!! Very important problem for my project... We are using a lot of this feature to control access to specific layout by asking for a password using "show custom dialog" with input as password characters... On iPad 2, it is now always crashing... but not on iPhone 4.
I really need a work around... to continue our project!!
Testing has been able to replicate the problem consistently, but they have found a workaround. If you put a .75 second delay before the Show Custom Dialog, it will not crash. That is,
Pause/Resume Script [Duration (seconds): .75]
Show Custom Dialog [ <your dialog information> ]
Using .5 seconds still crashes.
At this time, a slight delay is better than a crash.
Please report back if this works.
Sorry, but it's not working... for me.
Still got a crash every time...
I really appreciate your help because we are in production process with 14 iPad. I was using the Signature from (http://campsoftware.com/products/qc-signature-capture/), I have been involve in the solution with them. Now that FileMaker includes that feature, I was so glad... but now I need to found a workaround rapidely....
One workaround for avoiding show custom dialog (I often find it too limited for my needs), is to use New Window to pop open a new window for capturing the input. (This allows you to format your input fields with value lists and stuff.)
If you download the Known Bugs List database, you'll find several examples of how this can be done. Just be careful when you script and test your own. The method in this file uses an infinite loop with allow user abort [off] to make the small floating window modal just like a custom dialog. If you don't include at least one button on the floating window that uses halt script to halt this infinite loop, you can be trapped into a situation where you may have to force quit FileMaker.
Why not allow us to roll-back?
it's not fair to those of us who support you from the early on-set that we are forced into debugging version after version.
Some of us have ipads & iphones deployed in mission critical situations, and you put all of our credibility at stake when your product fails like this.
We have placed iPads in the hands of dozens of medical professionals across the country to manage important client medical files, so a scriptstep like custom-dialogue appears frequently throughout our solution.
I am simply amazed that something like this could get through testing and actually be released.
Pause/Resume Script [Duration (seconds): .75] - Does not work in our solution
Seems to work ok when there are 2 input fields and both have data entered in to them - we agree, this has worked for us.
Is this still reproducible if you increase the delay a bit more? We've also found that dismissing the keyboard before pressing OK will help avoid the crash.
I've also sent you a message with some additional questions on your post. Please check your inbox at the top of this page.
Can anyone confirm whether using New Window to open up a small window instead of using show custom dialog works with FM GO?
I've had a single report elsewhere that they couldn't get New Window to open a window of the correct, specified size on an iPad.
It does not. If you make a window sized smaller than the iPad screen it still takes up the whole screen.
TSBear - Just to let you know the .75 second delay works in my solution. Thanks for the tip.
Suggestion: create a new file and a small table with a few fields, no scripts. Now test your input and see if your experience the same problem.
Test under the same conditions of your users and if you can have one of them test the file.
If the problem is not reproducable using this new file, the problem could be with your working file perhaps with file damage, perhaps with to complex of a script, triggers, timers and all that. Calculated fields, custom functions and so on.
Since Go works via wifi and G4/G3 there are delays and drops that are not part of a direct connection or single user mode. I had a beautiful and complex system of working with graphics that ran like a dream on my new local laptop but when I put it in the cloud using a weak but fast wifi signal, Filemaker constantly stopped working and when it did the file took forever to do its thing. Weak signal, big file, complex things to do....not good for wifi.