AnsweredAssumed Answered

FMPA Freezing, won't respond until I press 'escape'

Question asked by realgrouchy on Feb 14, 2017
Latest reply on Mar 16, 2017 by realgrouchy

I'm not sure exactly how to describe this issue. FMPA is 'freezing' on me, which is to say that I can navigate through records, but all the menus are greyed out and buttons don't work. (I thought I posted this last week but the draft post didn't get posted)


I believe it happens when I'm in the Script Workspace and my cursor is in the calculation section of an If statement (expanding the line, but not opening the calculation dialog, or perhaps even just with an unsaved script), and then I click on a layout element in the same database which triggers a script (not the same script as the one I'm editing in SW. In this case, I clicked a tab that triggers a script).


The window essentially freezes. I can open and close the Data Viewer and the Script Debugger (which doesn't show any script calls). If I press the escape key, it looks like the script proceeds, but on one of my more complicated scripts it is skipping a lot of steps and not cancelling when it's supposed to (I have an $~ENDSCRIPT variable that is populated when the user presses "Cancel" in a custom dialog, and all subsequent steps are designed to be bypassed if $~ENDSCRIPT is populated, but it seems to be ignoring this. (Luckily I was only using test records so no data was damaged.)


If I press "escape" when the Script Debugger is open, then the script call seems to register, but it does that weird stuff described in the paragraph above. I tried checking off "disable script triggers" but either the checking off didn't take, or the setting cleared by the next time I looked at it.


I thought I had found the source of the problem earlier this week: a different, older database that I had open (and which one other shared user had open remotely) had an old reference to a data table in the first database I had open (I had renamed the newer database file so the older database file couldn't find the table because it couldn't find the file under the old name). The older database was open in a background window because the same colleague was using it. When I moved all the other windows out of the way, I saw (earlier this week, not this time) that there was a dialog open on that window which said that the related table couldn't be found. I thought relinking the table to the new name of the main database would make the issue go away, but it's still happening.


Another way this error manifested today (2017-02-14) is that I have two single-step buttons on a layout, one which sets a variable, "$$~HideCertainLayoutObjects", and the other one which triggers a Refresh Window step. When the problem occurs, if I press the button, the script doesn't actually trigger until I press "esc". If I have the Script Debugger on, the script step doesn't even appear in the debugger until after I press "esc". Most of the my data-processing scripts will write to a Log layout, including the one I had unsaved changes on, and there are no records of any processing scripts being run today. Two users did have the database still open overnight.


I am using FMPA 15.0.3 on OSX 10.10.5 with the file hosted on my computer, there were two other users who have the file open via local network sharing. Restarting FMPA is the only thing I've found that works, which is cumbersome because I often have a colleague who has left it open and isn't at their desk.


I couldn't imagine where to begin to try to reproduce this issue. I'm just hoping that someone will recognize this behaviour and point me in the right direction of how to fix/prevent it.




- RG>