2) Freeze window freezes what is seen on the screen as long as the script is running. The window will update when the script ends. Refresh window steps will update a frozen window. I believe that in Windows Systems, that Freeze Window may actually refresh the window when it executes so you may have a case where script 1 perfroms script 2 and a freeze window step in script 2 updates the window frozen by script 1. I may not be remembering that correctly, but I think that's the case. Also look out for layout based script triggers on your second layout that kick in when go to layout executes and which may perform scripts that refresh your window.
3) Freeze window is a script step that's been around a long time. In older slower versions on older slower systems, a script with the window frozen could run slightly faster than the one without the freeze window as it used fewer processer cycles to update the screen with each change to data or change in layouts. It is not web published compatible, so do not use it with with IWP scripts or it will prematurely halt your script. With today's systems there is much less need for this script step. I'd experiment with removing the step from all scripts and seeing if there is any noticeable difference in how the script executes. If I get a screen update that I don't like, I'd first check for any refresh window steps, then add a freeze window step to the main script at the earliest possible moment and not in any sub scripts. Then I'd test to see what happens.
a belated thank you for the last reply... still tinkering with this to try and get a "progres bar" (a progress pinwheel actually) to work... still not quite there. one follow up question... is it expected behavior that a pause/resume script step disables a previous freeze window step?
Yes, pausing the script (which allows user interaction with your database during the pause) will result in a screen update.
thanks... i was afraid of that. i am trying to get a progress wheel to display when the program is going through a long process. i am using a technique i read about on another site which relies on an animated png. however, when the application if running through a long process, the animation freezes (doesn't refresh?), and if i use a quick pause/resume in each pass of the loop (assuming that is the nature of the delay... in some cases i have long processes which are not the result of a looping script), i loose my freeze window... i suppose i can live without progress bars until filemaker makes them native!
Do it this way:
go to layout with animated gif
pause to display animation
Freeze the window again before continuing the script.
i'll double check, but i think at one point i tried something like that, but after the freeze window step, even though the animated progress wheel was still visible, it stopped spinning (i'm assuming because so much attention was being given to the real script steps that the processor stopped whatever process enables the animation functionality... refreshing the screen?) and then even though the script was working, it had the reverse affect because it looked like it had crashed. that's when i tried using an instantaneous (anywhere from .01 to .1 seconds) pause/resume to refresh the graphic which did re-animate it, although with somewhat irregular motion, but this unfroze the window. to avoid this problem, i placed the progress graphic on a layout based on the same table as that in which the script was acting so i wouldn't all of a sudden "unfreeze" on some other layout, but that limits me to scripts based on a single table, or some slightly quirky screen behavior (multiple prgress wheel windows... one for each table referenced). but i'll try agin using the steps you mentioned... thanks!
Take a look again at what I suggessted. I think you missed a key detail:
Put the animated gif on the layout where you want it.
Any time you want to show it in motion with your pause/resume step, first go to that layout and do the pause/resume. next step in your script is to freeze the window again to keep the user from seeing any other layouts. Then your script can switch layouts, do what it needs etc, but then switches back to this layout every time you want to update the graphic with another pause/resume. This assumes that your pause/resume actually allows the gif to move--never tried that, but I've understood from your post that part was working for you.
I've done this with a simple counter or a text field that I progressively fill with text such as the * or | to get a crude progress bar.
you're right... i did miss the key concept... at least... that is assuming that i understand it correctly now. so i will have those three steps all within a loop, for example, and i will keep going back and forth between the progress layout and the "working" layout (albeit invisibly to the user) once for every pass through the loop. not once before and once after as i was attempting? so if there are 50 passes through the loop, i go to the progress layout 50 times, pause 50 times, freeze 50 times, and go to the working layout 50 times? i'll give it a shot... thanks again!
p.s. i wasn't able to get the gif to work at all for some reason but a png seemed to work fine (with the obvious exception of my trouble implementing it properly!)
one more thing...
it just occurred to me that in case anyone is looking for more information on how to implement this (and lest anyone think i was smart enough to figure any of this out on my own), i should probably mention/credit my original source for this information (i hope it is ok to post links on this forum...?). the following resources were very helpful to me:
and, as always... thanks to phil for helping with this and dozens of other issues!!!!
Links are posted here all the time (wonder if SOPA/PIPA will change that?).
You can also post the link text, select it and then use the chain tool at the left end of the Post A Answer tool bar to paste the link text again to make it clickable to save others the inconvenience of having to copy/paste your link into their browser URL box.