In FileMaker Pro Advanced there is, in the Tools menu, Data Viewer shows any active global Variable(s). I don't know if that is available in regular FileMaker Pro. If not, I suppose you could just put them all on a layout, using Merge Variable (for each), i.e., <<$$variable>>.
If you are using FileMaker Pro Advanced, the Data Viewer will give you that info. You can also use it to modify the data stored in a variable. You could also create a developer layout with merge variables of all of your globals. You'll need to remember to edit that layout as you add new variables.
EDIT : Sorry for the redundancy, Fenton types faster than me.
Apologies all, I should have specified. I'm aware they are visible in the data viewer, but I was wondering if there was a function of sort that could be used in a script to grab the current global variables without naming them.
You could create an unstored calculation of all the globals.
$$GLOBAL1 & ¶ &
$$GLOBAL2 & ¶ &
That will give you a value list of all the established variables. You still need to edit the calculation as you add new variables.
If you only want the variable data and don't need to know which variables are empty, the list function would be better,
That would remove the empty values.
That's a good idea. I feel like the maintenance of that list could be a bit much depending on the solution but it's certainly viable in those with smaller sets of global variables.
Why do you need it? Feels like there should be an easier way to achieve what you have in mind.
+1 to Wins comment.. Why would you need such a construct? If you are creating so many global vars that you can't easily keep track of them maybe leverage a table of only global fields?
Every file I create has a table called simply "F" (for "file"). It has exactly 1 record. It contains a field called "One", a calculation = 1. So does every other table in the file. The "One" in each table is linked to the "One" in "F". Table "F" contains all my global fields for that file, organized by subject, so they're available to every other table in the file at all times. In particular, this is where I store all the default values I need for newly created records.
Table "F" also contains some fields that are not globals, because I want any user to be able to change them and have the change show up on the screens of every other user. For example, sometimes I have standard boilerplate text that can be pasted into an outgoing letter at the click of a button, but the boilerplate changes periodically, depending on what major holiday is coming up. Anyone can change that to reflect the next holiday.
Richard - you should look at Todd Geist's Selector Connector module on modularfilemaker.org.
What that said, I'm not exactly sure how your comment relates to the Global Variable topic being discussed. Maybe you could clarify for me.
Sure. The way I do business, all the global fields appear in Table "F", so I always know exactly where to look for them, and I can organize them any way I want under the "Fields" tab of "Manage Database".
If you want to know about the values the globals have, rather than just their names and characteristics, it's ridiculously simple to just create a separate layout whereupon they're all displayed.
Richard S. Russell wrote:
Every file I create has a table called simply "F" (for "file"). It has exactly 1 record. It contains a field called "One", a calculation = 1.
You may want to reconsider that from a security point of view. Having a "one" field is an obvious attack vector that will give the attacker access to all records from any context.
I'm retired and do all my database development pro bono for small, single-office non-profit organizations that couldn't conceivably afford me if I were charging market rates. They are so far down the list of hacking targets that they're effectively invisible. It would literally be easier for someone to just back a truck up to their offices and steal all their computers and filing cabinets. If anyone were inclined to do so. Which nobody is.
Your advice is probably a relevant cautionary note for people working on juicier targets, tho.
if all the fields in "F" table are globals, hence accessible from any context in the session, why do you need the faux cross join?