Can you describe your set up in more detail. What you describe should not require any extra step to get the field to update. Set Field alone should be able to do the job.
My understanding of what you have set up is this:
You have two tables linked in a relationship:
ON a layout based on Table1, you've added FieldA from Table2.
If so, then Set Field [Table2::FieldA ; "Somevalue or expression here" ]
should not need any additional script steps just to get FieldA to update.
Note: there are a number of possible cases where an added script step is needed to get a refresh and one of those may be what you have encountered here. If so, did you try using Commit Records (or just clicking a blank area of your layout which also commits records) to get things to refresh?
Thanks for the response.
The problem isn't to do with related fields, but ANY field that is in a different FileMaker file to the layout and script that is making the change.
I am using the separation model, so the layouts and scripts are in an interface file and the tables are in a data file.
When the refresh object step is performed on a field object which is a field from a different FileMaker file, the field value is not refreshed.
Commit records does not refresh the value either. The only step that works is refresh window, which would be fine in most circumstances but has performance issues over WAN on heavy layouts.
In which file is the script that modifies the data? The data file or the interface?
The script that modifies the data is in the interface file.
Then I'm puzzled by what you report. Just to be sure, I created a data file and an interface file, set up a layout based on an occurrence of the table from the data file's table and ran a simple script with two set field steps. The fields both updated as expected and with no extra "Refresh" step needed.
What am I doing differently?
Thanks for continuing to work on this.
I have just tried to recreate in a fresh file but cannot do so. I though it might be due to the original file being hosted on FM Server, but even after uploading my test file to Server I am still not able to get it to happen.
Unfortunately, I can't send the files that have the problem. I will do a little more work my end and get back to you.
To give a bit more detail: After setting the field with a status message "Loading..." The script performs an action that takes some time to complete, so a test would need to build in a delay where the script is still running for long enough to see if the field has updated during the script rather than after (due to the implicit refresh window step at the end of every script).
If I go through with the script debugger the field updates right away, without the refresh object step, which seems to be normal behavior for the script debugger, which seems to always refresh the window after every step.
Also, the problem is solution wide on the system I'm seeing it in, it doesn't just happen on this one combination of layout, table and script.
As I say, I'll do what I can to reproduce in another file and get back to you. If I can't manage that, I'll just strip everything I can't send you from the original files and send them over.
Layouts don't automatically update while a script is running. You might try using Pause/Resume Script to put a small fraction of a second delay after the set field and see if that resolves this issue.
Thanks Phil, I think I'm beginning to understand now. To summarise
- Refresh object doesn't update an object mid-script, so can't be used to update script status fields such as "Loading..." or "Sorting..."
- Putting in a short pause after changing a field in a script does update objects, but I'm not sure if this is any better than a refresh window step, performance-wise. I would think not as it updates all objects on the layout.
So perhaps this isn't so much a bug as a misunderstanding on my part of how Refresh Object is intended to work.
Note: In my previous post I said I couldn't reproduce the issue in other files. I now realize that this was because I was using "Pause/Resume Script" to simulate a long-running script, which leads a window refresh.
Thanks again for your help.
It has been my experience that a "pause" is much less drastic than Refresh Window [Flush Cached Join Results].