Hmm, that's a really old script sample that you dug up!
I posted it before I knew that Refresh Window [Flush Cached Join Results] was a script step best not used if you can find an alternative.
1) On Record load would be a trigger on the "Main" layout. It is needed to update the found set on the images layout every time you change records on Main as well as the first time you access the "Main" layout.
2) A serial number auto-entered in to a field of type number should work just fine.
A simple way to avoid the Refresh Window [flush... step:
If you have FileMaker 14, try the new refresh portal script step
In older versions, set up a global field in Main, gImageID. Link a different table occurrence of Images to Main like this:
Main::gImageID = Images|Selected::ImageID
and then use Set Field [Main::gImageID ; Images::ImageID ]
instead of: Set Variable [$$ImageID ; Value: Images::ImageID]
Your portal would then be set up to refer to Images|Selected and you'd use Commit Records in place of Refresh Window.
And now that I think about it, this last modification no longer requires an portal at all. The container field can simply reference the container field in Images|Selected and you won't need any portal for this.
When we make the $$ImageID script trigger On RecordLoad in the "Main" layout, the database stalls on us for some reason. In order to fix this, we have to go to a FileMaker Pro Advanced database and use the Script Debugger to stop the script.
I have attached a few images of what we have so far for our three scripts: $$ImageID, Next button, and Previous button. Maybe you can catch a mistake that we haven't been able to see yet.
Thanks a lot, Phil.
Attached is the image of the Next script. The Previous script is exactly the same.
Hmmm, didn't consider that this script trips its own script trigger. The Go to Layout [Original Layout] step will trip the OnRecordLoad trigger and everything starts all over again and this then becomes an infinite loop.
The script, however, can be modified like this.
If [Not $$TriggersOff ]
Set Variable [$$TriggersOff ; Value: TRUE ]
Put rest of script here
Set Variable [$$TriggersOff ; Value: False ]
That return to the original layout will still trip the OnRecordLoad trigger, but now the second call to the same script just exits without doing anything and you are no longer trapped.
You'll need to use this kind of strategy on your previous and next scripts as well.
This is reminding me why I don't do this in this particular fashion anymore.
My more recent efforts similar to this script would pull that list of Image IDs into a global variable and and I'd pull different Image ID's from that variable instead of changing layouts and thus not tripping script triggers.
Ok, thank you. When you say "Put rest of script here," does that mean the entire $$ImageID script I referred to in the images above?
Your help is much appreciated. We got that part to work. However, looks like the problem now lies on the "Next" script. When we click on the button, we realize the selected record on the "Images" layout does change to the next or to the previous record. However, the images in the "Main" layout do not change at all. Any ideas why this might be happening?
If you are using a portal filter, then you need your script to use either Refresh Window [Flush Cached Join Results] or Refresh Portal to force the filtered portal to update after the variable changes value.
And if the field named in your refresh object script step is the name of your container field, this is the wrong thing to use with refresh object anyway. (Object names are assigned to layout objects when you select them in layout mode and then enter a name into the inspector's name box.)