One of our collective pet-peeves at Soliant is when a developer writes code that messes with a user’s state…
In FileMaker that often translates to changing the found set of data, reloading the layout which then sets tab panes to their defaults, and so on. It’s annoying and disorienting for the user. We try not to be dogmatic — we’re huge believers in pragmatic design — but this is one rule, I think, we should all live by: leave the crayons and paper like you found them. Don’t mess with a user’s current state. In FileMaker Pro if you’re running a script that needs to change context somehow, preserving state is easy: create a new window.
Jeremiah Small put it well in a recent email:
“This can be used anywhere you need to preserve found set, sort order, window positioning, etc. It also works for cwp, incidentally, for the same purpose. Set Variable [$windowname; Value:“Process”] Close Window [$windowname] New Window [$windowname] Close Window [$windowname] The close at the beginning is prophylactic, in case anything ever happens to cause the process to abort unintentionally, you won’t proliferate identically named windows off-screen, potentially causing context ambiguity. Remember, if you want to use the found set and context of your current window as the basis for some process, creating a new window clones the found set as well.”
Now that’s all well-and-good, but it’s not necessarily the best way to do things. I hope Jeremiah will forgive me for taking his example one step further.
When you create a new window in FileMaker, even via a script and only in order to run an automated process, you’ll be essentially cloning that window state and loading it. That means that any processing triggered by the window will occur: summary fields, unindexed calculations, portal sorting, and so on. Depending on what’s on your layout, you can pay a high-performance tax by opening a new window. So let’s modify Jeremiah’s example slightly:
Set Variable [$windowname; Value:“Process”] Close Window [$windowname] Go to Related Record [From table: {your same table}; Using layout "blank layout"] [New Window] <do stuff> Close Window [$windowname]By opening the window immediately in a blank state, via this GTRR workaround, you’ll not suffer the performance hit you might otherwise have paid by cloning the new window, while at the same time following the best practice of leaving the user’s state perfectly intact.
Yes true, and of course now we need to be aware of Script Triggers too, so the point is well taken.
Another technique is to create the New Window but with a width/height of 0 pixels, and a left coordinate of negative something large (ie -5000). Summary fields/unstored calculations etc only calculate when visible on screen. By making the processing window that small, these will not be triggered. By positioning it offscreen, it means the user does not see any unecessary and annoying flashing of windows when they click a button to do something.