Windows or Mac? The close button behaves differently on each platform if a script is paused: On Mac the paused script stops the close command from running. On Windows the close command can run.
My advice is to use the new modal window feature in FMP 12 and get rid of the window close box altogether. This will force them to use the button to mave the next step, and the button can be formatted to resume/exit/halt the current running scripts.
Can you post the script?
Is the last step halt script? This should cancel all scripts.
I am not familiar with the new modal window feature...I will check it out. This is the scripts I had going:
Script loaded on popup window to lock it:
Set Variable[$$lock;Value:"no exit"]
Pause/Resume Script [Indefinitely]
Exit Loop If [$$lock;"exit"]
I have this script assigned to a close button AND close functions (file|close and the red 'X') with EXIT current script selected before running script:
Close Window [Current Window]
Select Window ["CC"; Current file]
Set Window Title [Current Window; New Title:"CC"]
Go to Layout ["CC1" (Main Screen)]
Adjust Window [Maximize]
Show/Hide Status Area [Lock; Hide]
It all works fine on the button but NOT the close/red X. As I said the settings were done in FM11Adv. I have a feeling that the custom menu Action step got screwed up during the transfer and doesn't specify to "exit" current script before running the close script.
The problem is that I dont have FM12Advanced, so I have no way of checking the custom menu's once it was converted. I changed the close script and added:
Set Variable[$$lock; Value:"exit"] hoping it would break the loop but it still did not help. maybe the script got completely deleted off of the custom menu. I just wish there was a way to check.
If you can upload a copy or provide a link to it, I'll check it for you with Advanced.
Since you have 11 Advanced, you can get 12 Advanced as an upgrade. This may be your best path. The long term advantages of having the debugger and data viewer are well worth it.
Is it ok if I email it to you at the gmail address you have listed? I do not want to post a link to it for security reasons. Let me know.I GREATLY appreciate it.
Please do. Include any instructions I will need to get to the problem screen.
If you are in the US, please include your phone number so I can call you and discuss this if nessasary.
Sent your way Bruce. Thanks.
As we discussed, it appears that this is a bug in FileMaker 12. When the script executes the pause step keeping the pop up window modal, it prevents the custom menu script from being triggered when the X button on the window is pressed. Halting the script and the custom menu works correctly.
So there are two possible solutions, Use the new modal window feature in Open window and remove the pause step. Or just use the FileMaker button to run the script and skip the custom menu version.
"When the script executes the pause step keeping the pop up window modal, it prevents the custom menu script from being triggered when the X button on the window is pressed."
I *think* that this is how the close widget has always worked in Mac OS X: if a script is paused then the window cannot be closed using the window widget. The problem I always had was that Windows users could close the window and the script was left paused.
So IMHO it's not a bug but a change of behaviour for FMP Windows.
You might be right. The catch is that in FileMaker 11, the Custom menu and script fire when the X button is clicked. The steps in the script do their work and close the window. In 12, the Custom menu and the script don't fire, so with out another button on the layout to initiat the close script the user is stuck. So at the very least, it is inconsistent behavior between 11 and 12.
The fix is easy, use the new modal window feature and drop the pause step. At least in this case it is no longer required.
"The catch is that in FileMaker 11, the Custom menu and script fire when the X button is clicked. The steps in the script do their work and close the window."
With FMP 11 the behaviour is NOT consistent between Mac OS X and Windows. FMP 12 appears to have made the Windows behaviour the same as the FMP 11 Mac OS X behaviour. So it's a change of behaviour but a reduction of inconsistency.
I have done a test with FMPA 11.0v4 on Mac OS X 10.7.3:
A script is running:
Allow User Abort [ off ]
Pause/Resume [ infinite ]
Note that user abort is OFF.
The close window widget is DISABLED. The click never gets recognised. The script remains paused, the window cannot be closed.
If user abort is ON the window close widget is enabled and the click gets through. If the standard menus are enabled then the window is closed. If custom menus are enabled then the action assigned to the Close command is performed. In both cases the script will remain paused.
When run under the Windows platform the close widget is ALWAYS enabled, so Windows users can close the window regardless of the user abort status. The script however is still left paused even though the window is closed -- not a good place to be. To work around this I've always made a "modal" custom menu set where the Close command is assisged a script that does nothing, or alternatively the Close command is removed.
It appears that in FMP 12 the window close widget is disabled if user abort is off and a script is paused on both OS X and Windows.
It's only inconsistent behaviour compared to FMP 11 on the Windows platform. The behaviour of FMP 12 is now consistent between OS X and Windows with the FMP 11 behaviour on OS X.
Are you saying that if I add Allow User Abort [ on ] to the pause script, the custom menu will work as originally intended on both Windows and Mac?
The original script and custom menu worked on both Windows and Mac in FM 11 and Failed on both Windows and Mac in FM 12. The first line of the script that has the pause step is Allow User Abort [off].