Freeze Window itself will refresh the window, I believe. So putting that step inside the loop is not a good idea. You should be able to freeze the window at the start of your script and that should be it as long as there are no scripts with Freeze or Refresh window.
Since you report that your script is tripping script triggers any refresh or freeze window in those scripts might refresh the window when you do not want it refreshed.
Also, the window will not freeze when you run the script in the debugger.
every time the script executes GO TO OBJECT it actives a ON OBJECT MODIFY script. Here is the catcher: "When I check the object script triggers, there isn't a ON OBJECT MODIFY trigger running a script ... or any other trigger being activated.
That is odd and I'm not sure exactly what you are describing, but if you run the script in the debugger and you see a script pop up that is performed by a script trigger, you can see the name of this script. You can then generate a database design report and search it for references to that script. Go To Object should not trip the onObjectModify trigger as the data in no field is being modified. (The only script steps that I know of that can trip OnObjectModify are the insert script steps.)
Could it be that you have a script with "onObjectModify" in the script name but what is actually being tripped is the OnObjectEnter trigger?
Great insight. But...
There is a Filter 'Off' button on the tab that holds the portal "DuesPortal". When debug encounters the GoToObject DuesPortal command, it runs the DUES FILTER OFF script from the Filter 'OFF' button.
Why? The object does NOT iinclude the button. Can you make sense of it?
(DUES FILTER OFF is very few lines of code but there is something here I don't understand)
Thanks for your help.
Here is a pic of the DUES tab and Filter Buttons....
Thanks that enlightens me. If you have an OnObjectModify trigger on the tab control, bringing a different tab panel to the front "modifies" the tab control and trips that trigger.
If you don't want that trigger to be performed, you can use a global variable to control whether the triggered script is actually performed.
Your first script can include code such as:
Set Variable [$$TriggersOff ; value: True ]
Go to Object
Set Variable [$$TriggersOff ; value: False ]
Your OnObjectModify script can include code like this:
If [ Not $$TriggersOff ]
Put the rest of your script here
PS. By using global fields instead of variables and including them in the portal's relationship using the X operator, it's possible to set up a filtered portal that does not need a refresh window step to update the data displayed in the portal.
Yep. Worked like a charm. Great idea. Thanks Phil.
Here is a different script that is pretty straight forward. Even though Freeze Window is in the script, when the window is opened if 'flashes' over the main layout.
Shouldn't freeze stop this from happening?
Freeze Window freezes a single window. Your script has multiple windows and I believe that the new window command may also trigger a window refresh.
I guess I should take that feature request to FM... But, I would like to know your thinking/understanding of why such a seemingly simple command has so many undocumented exceptions. For example, if I understand you correctly, I freeze Window A. My code then executes a script that opens Window B. Doing the latter causes the Prior Freeze command to be revoked and the screen if 'unfrozen'. But if I open Window B and immediately issue a new Freeze command it would freeze Window B. (I wanted Window A to be frozen). Or, if I unfreeze or commit or open another window or run a script does any of these things I am unfrozen as of the execution of 'these things'.
Does FM intend to make such a simple command so complicated with unnecessary exceptions?? It seems like the whole 'freeze window' and all it's exceptions (situations that cause it to 'unfreeze') could be avoided if FM would modify the command with a command choice like 'until unfreeze'... 'until script close'... 'etc...
Or, is the real source of the problem my inability to grasp something..... (likely)
I have no idea why. I can only share the "what" based on my own experiences. Much of the time, Freeze window is not even needed as many scripts will execute so quickly that the step is not even needed in many cases, but when you do need it, it has to be used with care to keep the "flash" to a minimum. In one of my systems, I change to a layout with the same background color as the one I wanted to "freeze" to. SInce its a layout of nothing but buttons, this made the "flash" subtle enough that all you you see is the smallest of 'flickers' when this change takes place.
Thanks for the comment.
Am I understanding you correctly in thinking that when a script runs code to Open another Window, FM 'refreshes' / 'unfreezes' the prior Freeze? If that is the case it looks like there is no way, other than tweaking the color or size of the 'new' window, to avoid a screen 'flash' resullting from the 'new' window being opened. Do I have it right?
When I define the window, I define it 3000 px from the top and 3000 px from the left. This puts it off the application work area and, at least in OSX, produces NO FLICKER.
(It seems to work so far.... Comments?)
I'm a Windows user where one must either maximize windows or manage to live with a rather awful "window inside of a window" look where each non maximized window only appears within a single "application window". And when you have windows maximized, a New Window script step tends to resize the original window in unexpected ways when it drops out of it's "maximized" state.
I thus try to keep the number of open winodows at any given time to a minimum and thus do not have a clear cut understanding of when a frozen window will or will not "unfreeze" in every situation and on every platform. I've just had cases where new window forced me to jump through a few extra hoops to get things to work the way I wanted them to.
Thank you for the illumination.
On a Windows 7 computer I just changed several other 'blinking window' scripts to 3000 px from top and 3000 px from left. It worked great. The only noticeable side affect was the title bar slightly blinked. But it is much better than the flashing window popping on and off.
Just thought I would pass this along so that other frustrated, confused and perplexed 'freeze window' users might benefit.
Thanks again Phil