You can unfreeze Filemaker by clicking on the 'Continue' button next to 'Script is Paused' in Filemaker's sub menu. I am not aware of a script step that can perform this function which is a problem in FileMaker solutions that hide the submenu. Filemaker 10 did not behave this way and this issue can be very difficult to find for developers that hide Filemaker's sub menu since you can continue to use a 'paused' Filemaker solution to a certain extend but you will not be able to quit the solution in the end.
Thank you for your post, and I apologize for the late reply.
I am able to replicate the problem on both Mac OS X 10.7 and Windows XP. The Pause/Resume script will remain indefinitely when a second script is activated.
I have forwarded your posts along with my findings to our Development and Testing departments for review. I will keep you updated as more information becomes available to me.
The Pause/Resume script should not allow the user to make any changes throughout the duration of the specified time.
Why would that be expected behavior? Why should pausing one script prevent other scripts from running?
Many of us rely on being able to make changes during a paused script. Do it all the time with floating windows set up as pseudo-modal dialogs and to disable FileMaker's dreaded auto-sort when the user needes to edit fields specified in the current sort order... And these changes often require running a script.
Thank you kindly for your replies. I must have misinterpreted the behavior of the 'Pause/Resume' script step in conjunction with the 'Allow User Abort [Off]' script step.
I have only used the 'Pause/Resume Script [Duration (seconds): 0]' script step after the 'Freeze Window' script step to redraw a screen while avoiding the flickering produced by the 'Refresh Window' script step. Of course FileMaker 11 updates the screen automatically without flickering after the script has ended. I was able to simply remove all 'Pause/Resume' scripts steps from my solution to avoid any application freezes.
Since I have the attention of the two most valuable contributors to the FileMaker forum I would like to find out if there is a way to lock FileMaker's internal window controls at the top right corner that appear whenever a runtime is opened in Microsoft Windows. Since the Microsoft Windows version of FileMaker 11 does not flicker anymore it is now possible to develope cross-platform interfaces that not only look and feel modern but also behave identical on both platforms even if multiple windows are opened. Two separate runtimes solutions can be run at the same time in Microsoft Windows with each of the solution having fully independent windows by simply renaming the file extension of one solution. Of course as soon as a Microsoft Windows user mistakenly tries to control one of the opened windows with FileMaker's internal window controls he looks at the traditional 'window in a window' which can be very confusing.
You cannot, as far as I know, avoid "window in a window". I would love to do that, but can't. I can minimize it's effects by using maximized windows and resizing the background window out to the largest possible size that fits inside the application window just after opening a new window to use as a pseudo dialog box. I'd also love to be able to hide all the window controls, both from windows and Filemaker so that it looks like a true dialog box, but can't do that either.
What I can do is use Allow User Abort [off] and an infinitely looping script:
Buttons that close this window use Halt Script--either as a script step or button option, to end the infinite loop.
to keep the window "modal" as this keeps the user from interacting with any other windows until they close the psuedo-modal window. This will, incidentally, disable the close button at upper right unless I specifically add a custom menu that uses a script as described above to close the window.
But you said "in a run time".
That confuses me. You can't close windows by clicking this button in a run time. I've, (grumble, grumble), had to add extra close buttons to the layouts of such windows before releasing them as run times for that very reason.
If you are intereasted in seeing Psuedo-modal dialogs in action, with code that checks for Mac or Windows platforms, see those used in my Known Bugs List database.
@TSGal, you indicated that you could reproduce the "bug". Do you still see it as a bug? If so, please explain the issue so that I can update my DB and Known Bugs List Forum Thread accordingly.
Thank you for very much for the database of all known bugs. It will surely come in handy.
My requested feature would only benefit developers who create solutions that do not require modular dialog boxes. Since FileMaker 7 combined all the tables into one file there is rarely a need to open a second window. When an interface is build within a single window with the help of portals and tabbed panels FileMaker's internal maximize/minimize window controls that appear in a Microsoft Windows runtime become unnecessary. The window can be changed by the default window controls of the operating system. I would simply like to be able to 'lock' the internal FileMaker window controls in the same fashion I can 'lock' the status area. It would avoid confusing the average computer user who wishes to control a window but clicks on FileMaker's internal window controls instead of the operating system's window controls.
Hopefully this feature request will be considered for a future update. Thanks again for your feedback.
The issue I logged is that whenever a second script runs while a Pause/Resume script step is active and Allow User Abort is set to Off, FileMaker Pro or a Runtime solution will freeze. Even though I wasn't able to reproduce the second part (Pause/Resume script step being executed multiple times with a pause duration set to 0 seconds), I also logged that, too.
Currently, Testing has not reviewed the issue, so I don't know how it will be categorized.
The problem is, that I can't get my XP system to freeze. That's what pulled me into this thread. I saw that you hadn't confirmed on Windows 7, so figured I'd replicate the issue in windoww Xp then check it out windows 7 so that we had a more complete bug report. Started with XP to see if I could get it to freeze and couldn't, which led be back into a more careful read of the original post to see what I was missing and spotted that statement that I was questioning earlier.
I run scripts in FileMaker all the time with one script paused and don't see any freeze in FileMaker--that how I manage my "pseudo modal" dialog windows so that users can't interact with the back ground window. They can trigger other scripts, edit data in the dialog and then use a script to dismiss the window and halt an infinitely looping script that has a single indefinite pause in the loop body. In my tests, I used pauses of 10 and 20 seconds and could still run a second script while the first was paused. Didn't try a zero duration pause so maybe that was the key detail here...
"Freeze" is probably not the correct word to use. If you follow the steps in the original posting, you can see the potential for a freeze.
1. Create a script that Set User Abort [Off] and pauses for 10 seconds.
2. Create a script that adds a new record.
3. Create a button on the layout that executes the second script (new record).
4. Show the Status Toolbar and execute the first script. In the Toolbar, you will see Script paused <Continue>, and after 10 seconds, it disappears.
5. Execute the first script again, and before 10 seconds elapses, click the button to add a new record. Click outside the field(s) to commit the data. The Script paused <Continue> now stays indefinitely.
The point here is if you don't have the Toolbar showing, how would you know a script is paused? If you create a Runtime solution, how would you quit? It's the perception of the program freezing. Is that clearer?
TSGal: Your last post sums it up beautifully - you are the best. PhilModJunk: You helped me tremendously with an issue I posted earlier this year. Thanks again for taking the time and most of all thank you both for being so helpful.
Using Windows XP and Filemaker Advaced 11v3, I ran this script:
Allow User Abort [off]
by selecting it from the scripts menu.
I then selected a second script from the scripts menu:
and clicked the back ground to commit the new record.
After the pause expired, the Continue button disappeared.
Hence my confusion.
Following the instructions to use a button to perform the script is enlightening and provides an interesting insight:
If "Pause" is specified as the button action, the "double pause" is what leaves the script paused. It's the pause from the button option that leaves the continue button visible. If I choose "resume" the continue button immediately disappears when I click the button.
Not sure, but this may be considered expected, but confusing behavior here.
Make sure you are not executing a script step when you click the button (as this will work), but are actually executing a script that only has New Record/Request.
Make sure the Status Toolbar is showing.
Run the first script. After 10 seconds, the Continue button disappears (as expected).
Noq, run the first script again, and before the time has elapsed, click the button to add a new record. Click outside the field to commit the data. The Continue button never disappears.
I can definitely reproduce the behavior reported. I'm just suggesting a different interpretation as to why it is happening--one that suggests that this may not actually be a bug, but "by design".
I did exactly what you described when I reported back in my previous post.Then I made one small change to the button options and the continue button vanished right on schedule. The difference is whether you specify "pause" for the button or one of the "resume, halt, exit" options for the button. The reason the Continue button is still visible, is not due to the pause in the script but due to the pause specified by the button option.