AnsweredAssumed Answered

Caveat for global variable ($$) use when returning to FMGo

Question asked by tcmeyers on Oct 29, 2010
Latest reply on Nov 8, 2010 by tcmeyers


Caveat for global variable ($$) use when returning to FMGo


Under (iPhone) iOS 4.1, FMGo 1.1.1, with the hosted files on FMS with the fmrestorelogin privilege set for the user, when I leave the app briefly to do something else, then return, the files reopen as expected, but a global variable that I used is filled with garbage. Interestingly it appears that global fields are restored just fine, but not this global variable. The variable is $$remlegend which holds a text string generated to be appropriate for a checkbox, generated at the setup script for the particular task the layout is supporting. I could use an unstored calculation field to do this same thing, but that seems wasteful.

It appears that global fields are restored on return to the App, and if that's the case it seems reasonable to expect global variables to also be restored, so I'm not sure if this is a bug or oversight, or my expectations are just wrong.

I've attached a screen shot that shows the layout with both a global field as a merge field <<iP_Bak>> and similarly a global variable<<$$remlegend>>. The next panel shows what the iPhone looks like prior to leaving the app, where iP_Bak is displayed as "Basics" and $$remlegend as "Remind to retake photo". The 3rd panel shows the display seen after returning to the app, after the short delay while files are reopened automatically. Note that iP_Bak is still correct as 'Basics', but $$remlegend is garbage characters. (In one case it displayed the IP address of the FMS machine and some other garbage, so it seems to be pointing to an incorrect block.) It seems like, at the minimum, if we can't expect $$remlegend to be preserved, it at least should be 'empty'.