The scope of $$ script variables

[SlimJim]

I have just written some scripts making use of the new $$ global script variables to pass parameters between scripts and I was getting some odd results. On monitoring the values of the script variables I discovered that the variables were not passing and it turns out the reason is that I was using a script in one file to call a script in another file.

The significance of the comment in the help file "global until the file closes" has now hit me. The scripts may be "global" in the file but they are also "local" to the file. The values are NOT passed from one script to another if the scripts are in different files (even though the files are related).

No doubt I was being optimistic in thinking that they would but I am annoyed to find that I have to go back to adding globals to carry the values (Still it's what we are used to!)

[highflyr]

if you are trying to pass variables between files, why not pass it as a parameter... ie.. set the parameter as $$myVariable as the first script step in the second file have "set variable" - > $$myVariable -> get(scriptParameter).

this would set variable as being "global" in the second file as well.

[comment]

That would get awkward with multiple variables. The question is, why call a script in another file at all - instead of defining a file reference in the originating file, and - if required - adding layout/s from the other file.

[SlimJim]

The solution was automatically converted from FMP3 and has 10 files. The scripts are part of an updating script which calculates running outstanding amounts on invoices at the item level (which includes both invoices and payments) and I was simply trying to streamline it using $$ variables. There are in fact 4 numeric variables to update and I agree that with some effort I could pass them together as a script variable but it's easier just to simply use 4 global variables (as I was doing in the first place). I have file references in the calling file so what you are saying is that I should add the layout from the items file into the calling file?

[comment]

If you're satisfied with the conversion as is, then why fix it if it ain't broken?

If you want to rewrite, then EVERYTHING is open for reinspection. Perhaps you don't need separate files at all?

[SlimJim]

If you're satisfied with the conversion as is, then why fix it if it ain't broken?

I can't argue with that. The conversion works pretty well like it used to (I think) I am currently working through all the scripts and testing that they still do what I expect them to. I was trying to use the existence of script variables to cut down on the number of temporary global variables and hit the problem I mentioned at the beginning of this thread.

[comment]

Well, the variables have to live somewhere. If you stop to think about Filemaker's paradigm in general, you will see it makes perfect sense for them to live in a file.

[ahhwhereami]

Well, the variables have to live somewhere. If you stop to think about Filemaker's paradigm in general, you will see it makes perfect sense for them to live in a file.

Absolutely. Since multi-file FileMaker "solutions" are essentially just based on what files are open at any given time, rather than being managed by a central management file, it wouldn't make much sense to have one central namespace.

Consider: If you had two seperate solutions open at the same time that both used the global variable $$x, they would likely interfere with each other... and both crash and burn.

Oh well, maybe one day :P

[SlimJim]

Thanks to comment I have resolved this problem using a file reference and a layout - another item that I will need to study more.

I would like to get back to the question of scope. In a Filemaker solution there are various kinds of variables (other than standard fields). My understanding is that we should think of $ variables as local to the script, $$ variables as local to the file, variables defined in a Let as local to the calculation, global variables as local to the user (or local to the machine?).

I don't know if this list is accurate and I would like to know, and at the same time have I missed any out?

It would be very useful to have a simple statement, and I don't mind who gives it so long as it is accurate, as to the scope of the different variables that can be used. I guess that by reading various bits of the help file you can find out but I would like it all in one place.

[comment]

There are also some Filemaker's in-built variables, e.g. found set, sort order, RecordNumber, etc. that are local to the window.

Note that variables defined in the Let() function are local to the Let statement alone. Trickle down in nested Let()'s works, but not the opposite.

[CobaltSky]

Note that variables defined in the Let() function are local to the Let statement alone.

Interestingly, this is not necessarily so.

If the name of a variable declared within a Let( ) statement is prefixed with $ or $$, it will be scoped beyond the statement, as a local or global variable.

A Let($variable = ... declaration which is evaluated when no scripts are running is scoped to 'Script 0' and will be accessible anywhere in the file except when a script is running. A variable similarly declared while a script thread is active (whether evaluated within the code of the script, or elsewhere in the file) will be accessible for the duration of the script.

And, of course global variables declared in a Let( ) statement:

Let($$variable = ...

- can be accessed anywhere in the file for the current session (until/unless they are explicitly set to null).

This has a bunch of implications, all of which are exceedingly cool. Among them is the fact that Let( ) can be used in combination with Evaluate to provide indirection of variables - ie the name of the variable being declared can be determined by calculation. Plus a load of other possibilities... :

[SlimJim]

]

A Let($variable = ... declaration which is evaluated when no scripts are running is scoped to 'Script 0' and will be accessible anywhere in the file except when a script is running. A variable similarly declared while a script thread is active (whether evaluated within the code of the script, or elsewhere in the file) will be accessible for the duration of the script.

How do you keep control of this? Suppose you use a $variable in a Let outside a script, say in an Auto-enter calculation triggered by a New Record step and at the same time Set the same named variable within the script. Are they regarded as the same variable and evaluated in sequence, which may cause some mysterious problems, or does FMP regard them as different in some way even though they have the same name? I guess the first of these. Which presumably means you can pass variables from auto-enter calculations back into scripts!!

Is this really the case? Complexity beckons.

[comment]

This may be semantics, but I stand by my statement:

Variables defined in the Let() function are local to the Let statement alone.

Or, in FM Help version: "Let Function ... Sets varX to the result of expressionX for the duration of calculation".

If you happen, during the Let() statement, to declare a local variable or a global variable - as opposed to just plain variable - then the scope is extended, as Ray explained.

Suppose you use a $variable in a Let outside a script ... and at the same time Set the same named variable within the script.

While the script runs, the in-script definition is in force. When the script halts or pauses(), Filemaker returns to the calc definition.

A more interesting question is what happens if you define the same local variable with different values in two calculation fields, then refer to it in a third.

You would expect the first-created calc to take precedence, and it does - unless you click into the second field, then into the third. It looks like the last active calc will take precedence, until the window is refreshed.

[CobaltSky]

Yep, that's semantics. :?

They're all variables, but the scope is different.

That aside, it is not the location of the expression that results in a variable being declared, it is the timing of evaluation. Within its scope, a variable will persist until it is overwritten by another value or a null.

You're right that if the calcs are unstored, any action (such as refreshing the screen or clicking into the field) which causes the calc to re-evaluate will post a variable.

It is a very powerful feature. Though as someone once said, 'with great power comes great responsibility'. :

[comment]

They're all variables, but the scope is different.

Terminology is important, Ray. If three things have different scopes, then there ought to be three names. Lumping them together as "variables" doesn't work for me, at least not when scope is the topic.

Anyway, here's a little demo showing how easy it is to get FM confused about this.

confusedVariables8.fp7.zip

[CobaltSky]

Terminology is important, Ray.

Well, we're agreed on something, at least. : :