1 of 1 people found this helpful
Use two fields, one with local storage and one with global storage.
Use a script performed OnFirstWIndowOpen (see Script triggers in File Options) to copy the value from the local field into the corresponding global to make it universally accessible each time the user opens the file. You can also use a global variable instead of a field if you wish.
To make a change to the value that "sticks", you edit the value in the local field from which the global field or variable is initialized each time that the file opens.
Great, you already basically understand that global fields in a hosted file won't retain the value they had when the file was closed by a client... even if that's only you.
The trick is to store settings in non-global fields, typically within a 'system preferences' table or in a 'user' or 'user preferences' table (in the case of personal settings for each person logging in). BUT you also have global fields for these settings. Usually you would create a startup routine (i.e., OnFirstWindowOpen triggered script) to copy those values to the global fields in effect for the user during their session and available to all tables without building relationships.
Just be aware of context when modifying or copying data to the preferences fields.
I hope that's helpful.
I've got a few thoughts on this.
Create a script that copies the preferences values from static fields in the preference table to the global fields. Run it on file open.
If the first record in your preference table has the default values then its easy to load global fields.
If the globals might change for a specific user and require storage across sessions then on file close run a script that copies the globals back into the user's record in the preferences file. Adjust the on-open script to first find the user's preferences record before loading the global fields. If no record then use the first record for the default values.
Alternative 1) put the default values directly into the startup script and have it load the global fields.
Alternative 2) if these values are all for use in a single file use global variable instead of global fields.
The problem is that this file itself wont startup, because i only use it to store and read from it trouhg other files. So would it then really "startup" and run script i put into the startup option?
Btw. untill now I tried to use sperate fields and read from them with making the global field into calculatin field, which did not work too.
I must say this is very trick, maybe there should be an option so that global fields actually store data.
Hmmm. OK, whenever another file connects to this 'master preferences' file, it needs to perform the operation of copying the preferences from the normal fields to global fields. The global fields might be in that preferences file or in the file that reads and uses the preferences. This would still need to be done via script, rather than a relationship alone. That script can be the OnFirstWindowOpen script of the connecting file(s).
1 of 1 people found this helpful
So would it then really "startup" and run script i put into the startup option?
If it doesn't, you can use the OnFirstWindowOpen trigger in the file that the user does open first to perform the script in this preferences file to load the globals.
Or you move that table into the other file and have one less file in your system. Either approach will work.
Yes, its not working by itself as I thought.
But ok, thats an idea. So I simply add that to my firstloadscript in each file.
(Aha! Well, global fields actually DO retain their values. Just not the way you're currently expecting. If you create or open a FileMaker file locally on your computer, rather than hosted, and put a value in a global field, that value will be there after you close and re-open the file. Globals retain the value they had the last time the file was opened locally. If you added the field while the file was hosted, it will always have an empty value upon opening. This makes sense in a multi-user environment because of the way they store different values for each user's session. This is also why you should still have an OnLastWindowClose triggered script to clear 'session' globals: Because the next time you work on the file locally, whatever values the global fields had when you close the file will be the values appearing initially for all users, once the file is hosted again.)
Another option which bypasses any need to create a TO in each file to a preference file is to pass values using parameters.
You can base the prefences on account name, prefences, etc.
Your prefence file creates a 'blob' that it transfers to the other file.
For instance the current file can perform a script in the remote preference file that returns the blob.
The users script
Perform remot script
Do a bunch of stuff and put it into a variable, global field, etc.
exit script(return the stuff)
set var $result to Get(scriptresult)
Parse out the values to use in $result and proceed.
I've used this to bypass the hangups of needing a TO and I also encrypted the data before returning it for security reasons for those wi-fi scammers.