I can't find any help information on how to put a FMP8 Advanced $ or $$varia ble into a layout. When you try to put a field it appears only fields in tables/files. Knowing FMP history I think it is not possible but perhaps someone has a solution.

The other thing is how I can use a $ or $$variable to use it as a key to relate a table.

Please don't tell me that the only solution is to use again "OLD" global fields, I hate them.

Thanks.

Since relationships relate to fields, you would need to define an unstored calc with a reference to a global script variable, then set that variable within a script. But this is just as much work as defining a global field.

I'm thinking a regular "old" global is the better choice here. I don't know why you have such an animosity towards them (did they taunt you as a young developer of something??)

Thanks Ender for your answer. Did you try sometimes, to change the content of a Global Field in a networking environment? If you are the host in a peer-to-peer it's fine, if not, forget it. But if you put the bunch of money you have to put to get FMServer, and more money to buy a dedicated (?????) server and a lot, lot, lot of more many to buy a W2000 Server, because it's imposible to run FMServer in the same server you have all your users connected, the solution of our FM friendly company is, stop the service, copy the file with the global field you want to change to a other computer, change the content of the global field, copy again that file to the computer wher FMServer is running (but stopped), and start the service again. Do you thing this is something that follows the Computer Science General Rules of 21st Century, do you?

What's the difference between your desire to have a script set a script variable vs. having a script set a global field? Same thing. Using a script to initialize those globals is a pretty common technique that eliminates this need to take shared files down.

If you define a $$variable at the beginning script (that runs when you open the main file) it's alive until you close Filemaker.

If you define a Global field (besides you have to go to Define database, create the field as text or whatever, then enter to correct options and go to the tab where you can put it's a GLOBAL.......) to have that field available as a $$Variable, you need to be sure you are IN the file the Global field was defined or in a file which is RELATED to that file, an affair really difficult in Filemaker.

Perhaps in FMX22.5 (X=Xtrasupercalifragilisticoespialidousus) we would have the ability to use those strange pieces of information technologies market called .......... VARIABLES

Thanks

To access a global field it has to be in a table which has a table occurrence in the relationship diagram of your file. The table itself does not need to be in the file or even in a related file but it does have to be in a referenced file.

A $$variable, despite being called global, is only available within the file containing the script in which it is Set. If you run a script in one file and call a script in another file and try to use the same $$ variable you will find that the values of $$ global variables are not retained when moving from one file context to another. To my mind this is a very positive reason for running all your scripts in one file (interface file or whatever you want to call it) as you can then use $$ variables "globally" (to the file) and $ variables as "local" to each script

Hi Dan,

What you say is true, but carlosmenem's question was about using a script variable as a relational key, which is different from simply using it to replace a global field's role as a counter or a tool for passing values to other scripts.

But, since you brought it up: while passing values to other scripts could be done with script variables, I think script parameters would be better for this. In my mind, it's better if the values that a sub-script uses are passed explicitly rather than using a global variable, which might be set or changed from any script in the file. It makes the script more modular, like a function. Well, this could just be a matter of preference, as either way the developer has to take care that values are set appropriately so the subscript can see them.

Anyway, passing script parameters would overcome this need to combine files, for those that do not wish to.

[Off Topic a bit]

Hi Ender

I wasn't suggesting combining files I was suggesting making a front-end file which references all the other files and then run all the scripts and layouts in that one file. Regarding modularity of scripts now that we have script parameters and script results then they effectively are functions with Input and Output, local variables - FMI is getting there. The nest step has to be the ability to compile scripts (once we have them running properly). Unfortunately we see all too often on these forums users getting hung by startup script that they cannot stop