Buggy, unstable, ephemeral issues in FM GO 13
Operating system version
iOS7, Windows 7
Description of the issue
I am posting a list of recently encountered issues in one issue report. They cannot be reliably reproduced as they seem to occur at random.
Most have occurred in more than one completely different file. Some have been reported elsewhere in the forum. Some have not been reported to my knowledge.
I am reporting them all in one report as there are overlapping similarities and when viewed as a whole, suggest that there are some basic stability, system refresh and window management issues in FM GO that need to be looked at by the engineers at Filemaker Inc.
Steps to reproduce the problem
FM GO files randomly open in a kind of "read only" mode. Fields do not retain edits. You may or may not get an error message that the record is locked because it is being edited in another window even though no other windows are open at the time.
If you double click the Home button and flick the window for FM GO upwards to close the FM GO app, you can re-open the database and it will once again function correctly.
This one has been reported in the FM GO forum several times but has not yet been officially acknowledged as an issue by TS personnel.
In what may or may not be a different manifestation of this issue, I have one DB where I tap a field to perform a script. The script copies data into a set of global fields, then opens a new window with a layout that displays said global fields for editing. Periodically, this window opens with all fields blank. Closing the file down and restarting FM GO fixes the issue until the next random occurrence.
Opening a new window can result in the current window spontaneously closing--perhaps due to layout corruption. This bug created the appearance that the DB was crashing because a script was closing the last window left open instead of the next to last window.
After placing an unstored calculation field that used the WindowNames function to list all currently open windows on several layouts and putting some pauses in the script, I was able to determine that the script, which opened window 2, performed some tasks, opened window 3, performed more tasks then closed window 3, then Window 2 was closing Window 1, because window 2 was not open when it should have been. By replacing the layout that was current when Window 2 was opened with a new, rebuilt from scratch layout, the issue was resolved. Please note that each time I tested the script in FileMaker Pro, the script behaved as expected.
I had a "use values from a field" value list that listed less than 100 text values in a value list. I then used a script that used Filtervalues and valuelist items to check to see if some text matched one of the values in this value list. When tested in FileMaker Pro, the script behaved normally. When I tested it in FM GO, the script failed to produce the expected result.
My original conclusion here was that there was a bug with either this type of value list, a special calculated key used in field 2 to sort them in an arbitrary order or the valueListItems function when the script was performed in FM Go 13. But when I created a sample file for an Issue Report to post here, the sample file worked correctly in FM GO. I then defined a new value list with exactly the same features referencing exactly the same fields as the first and replaced all uses of the original value list with this new value list. The script then functioned correctly in FM GO.
I've added a scrolling Popover feature to an upcoming release of the Known Bugs List Database as described here: http://forums.filemaker.com/posts/a568e2a481. I set up a script to open the popover automatically the first time that the user accesses the main iPhone layout. It sets a global field to 1 so that subsequent visits to the layout do not automatically open this popover. (Go To Object can open a Popover.)
But while hosting the file from my Laptop's copy of FM 13 Advanced so I could Use FM Go to test my design, the popover would not open consistently even though I was being careful to keep the global field empty. When I tapped a control on this layout, the Popover would briefly flash and then disappear. (I have the field that fills the popover set up as a button to close it when tapped.)
After a lot of wasted time replacing different design elements with new objects, I discovered that if I closed the file on my lap top and then re-opened it. It would function normally until I made some new design change to the layout at which point the problem recurs.
Throughout dealing with all of the above, I periodically got an error message on the iPhone that a record could not be modified because it was being edited on the host computer. This occurred even though I made sure that the cursor was not in any field. Clicking a blank layout location to commit the record did not resolve the issue. I had to put the current layout in Layout mode to make the error message stop appearing.
The above issues have occurred in three different files. But many or similar issues have occurred in at least 2 of the three.
Recovering files has not found any issues with the files--even when I later fixed the problem by removing and recreating a feature in the file.
Using advanced recover options to rebuild all indexes in the file also has not produced any noticeable differences in behavior.