It would be nice to do this, but go to layout is the only method available for establishing "table occurrence context" for your script. This can create issues when you change layouts and a layout based script trigger such as OnLayoutEnter or OnRecordLoad pops up in the middle of your running script and produces undesired results that affect your script results. Sometimes you have to use hidden "utility" layouts, blank, based on the desired table occurrence, but hidden from the layout menu when in browse mode, to get the correct "trigger free" table occurrence references.
I once used the Feature Suggestion Form to suggest the following new feature in FileMaker:
Set Table Occurrence Context ["TableOccurrenceName"]
End Set Table Occurrence Context
to do exactly what you describe here. Feel free to use the above link to make your own suggestions or to "chime in" on mine if you think that it has merit.
Oh yeah, Go To Related Records can also be used to change context, but then that's just another way to change layouts...
Phil, you are a confidence booster! I'm glad I stumbled on to the same solution that you use. Thank you!
I did add my post for the Feature Suggestion as you posed it. Perhaps we'll see that happen soon.
"... use hidden "utility" layouts, blank, based on the desired table occurrence ..."
It doesn't seem to matter whether this "utility" layout has any fields on it or not to my particular script.
Yep. All that really matters is the table occurrence selected in Show Records From in layout setup...
Keeping the layout blank isn't really necessary, but in a few cases, it may avoid layout update delays if there's a summary field or other such layout object on it instead of leaving it blank. (And Freeze window should prevent even those delays so this is more a matter of Preference, than necessity.)
In another post ( http://forums.filemaker.com/posts/fd36adf0c8 ) I've discovered (in my own mind anyway) a "gotcha" with changing context within a script.
Without thinking it through, I placed a call to a script on a Layout's OnEnter Script Trigger. The part I didn't think about was that that script changed context by changing layouts.
When the script step [Go To Layout (Original Layout)] executes, the OnEnter Script Trigger goes off and runs the same script again. An endless loop that I can't find a way to stop, because it executes as soon as the file loads.
I think changing context via this method should proceed with caution. Perhaps FM Advanced has a way to break this circle.
I've encountered the same issue and the follwoing workaround can be used in either version of FileMaker:
Enclose your layout based trigger inside this pair of If - End IF steps...
If [ Not $$TriggersOff ]
Set Variable [$$TriggersOff ; Value: True ]
#Put your script steps here
Set Variable [$$TriggersOff ; Value: False ]
This keeps script steps inside the If/End If from tripping the same script endlessly. This method can also be extended as a general way to disable all script triggers temporarily by using this code in all such scripts so that manipulating this one variable's value turns them on or off.
Phil, do you know of a way to break this cycle once it's started? (Without the script mods you suggested.)
Since you have advanced, open the script debugger and use it to halt your script.
If you haven't used Allow User Abort to prevent it, you can also press Esc (windows) or Command-Period (Mac) to halt currently executing scripts--which also works with regular Filemaker.
Once you've halted the endless chain of scripts, enter layout mode so you can disable the trigger until you get it fixed.
I thought Command-Period (Mac) would work, but it doesn't. Actually, nothing short of Force Quit works.
You can't just use the script debugger to halt the script, enter layout mode and change the trigger?
Sorry I wasn't more clear. My Advanced won't be installed until Monday or Tuesday, so I'm stuck with just Pro for now.