Right. And, @xochi - global variables being per-session, per-file also applies to the same account logged in using some other client: they do not share across those clients, even using the same account.
1 Like
What you describe is not a bug, it is known, expected behavior. Though I will say that (like many things), it is not documented very clearly, and that causes a lot of confusion.
@DanShockley's description of variable scopes are excellent. I haven't heard the "script-zero" reference before, but the description of "it sticks around while whatever defined it exists or is being evaluated" is how I think of it. And calculations can be anywhereā¦ field definitions, Data Viewer, countless places on layout objects, etc.
If you want your field or layout $variables to "interact with" script variables, this can be a powerful feature. But if you weren't expecting it, it will seem like a bug and will drive you batty.
Unless I really want this, I stay away from using $ or $$ anywhere but a script. Inside Let statements, I want to use something to help me see visually that it is a variable, and also avoid reserved words or other function names. I've used ~VariableName because it stands out and is easy to type. A colleague of mine also got me in the habit of using Ā¢VariableName. It was a clever way of denoting the desired scope significance. $$ for global, $ for script, Ā¢ for calculation. I suppose if you live in the EU, you could use ā¬ or Ā£, as needed. 
I would also caution that any variable, global or otherwise, is at most scoped to the current session, and avoid saying that they are scoped to the user, computer, etc. A user can have multiple concurrent sessions, in several ways: multiple computers/devices, multiple WebDirect browsers/windows/tabs, multiple instances of FileMaker running at the same time on the same computer, etc. This will all have their own session, with their own global scope. And variables do not transfer to PSOS sessions, so each of those need to re-establish context and variables, if needed.
5 Likes
A Tilde (~) for LET statement scoped variables is the norm that I have seen, but I like the Ā¢ / $ / $$ paradigm for scope using the monetary unit increments.
And ~, Ā¢ and _ variables auto complete with MBS Plugin in calculations as well as $ and $$ variables. So Ā¢ is one of the blessed prefixes.
2 Likes
More on this from the Claris help files, Let function
Once defined, variables can be referenced in any calculation within their scope. Local variables defined in a calculation are scoped to the file but are only available when scripts are not running. See Using variables.
The emphasis in that quote is mine.
What does this mean for local variables defined in "Hide when" calculations, or in conditional formatting, tooltips, or anywhere else that calculations can occur?
@RosemaryTietge, would you ask the Claris engineers to do an Under the Hood session devoted to local variables please?
+1 on using "~" for variables that only need to be calc- or function-based.
I wonder what the scope of a local variable defined in a text fields let statement?
Yes, this is a thing, strange and obscure as it is.
You can create a text field that contains a LET statement and place it off screen right with a hide condition. When the layout opens, the hide evaluates and the text field content executes the LET statement setting a variable.
Not a suggested path to use as it is just one more place to obfuscate code but it is functional.
How persistent this is is unknown; never checked.
It's persistent. And you'll be able to access that local variable from other layouts.
Blockquote And ~, Ā¢ and _ variables auto complete with MBS Plugin in calculations as well as $ and $$ variables. So Ā¢ is one of the blessed prefixes.
Yes, I do love how MBS auto-completes variables with ~ or Ā¢ prefixes within the calc engine. I do wish that it could detect $variables set with a Let statement elsewhere in the same script though. It seems to only detect ones explicitly set with Set Variable, if it's not in the same calculation. That also prevents me from using the "Check variable names" option, as it flags $vars set in a Let as undefined. Unless that has changed recently. I haven't tried turning that back on in a while.
Iām not at a computer I can test this on right now, but I believe that documentation is incorrect. I think I have seen $variables defined by layout objects be readable by (or cause interference to) running scripts.
I found that statement curious too.
We've got conversations here in the forum that started because local variables were leaking into running scripts from field calculations
1 Like
Agreed. I can understand how someone came to write such documentation, but I do not believe it to be accurate enough and/or precise enough.
I just tried this out, finally, in FileMaker 18 Advanced (v. 18.0.3).
A variable set by a buttonbar label was NOT visible (using exact same name) in a running script.
A variable set by a field calculation was NOT visible (using exact same name) in a running script, even when the script referenced the field to make sure its calculation was evaluated.
So, I guess the documentation is correct, and has been for a few years.
I'm pretty sure I remember 17 (or earlier?) DID allow for collisions between script/non-script usage of identical variable names.
But, this is a welcome change, if I'm right about how it used to work.
1 Like
Argh! was just bitten by this issue again today. I seem to have fallen into a development pattern where I do this:
- create a useful calculation as a
Set Variablescript step. - later, decide this would be even more useful as a calculated field.
- copy & paste my function from the script to the field definition (forgetting to change $var to var (or ~var...)
- end up with weird "impossible" behavior
It would be great if there was an easy way to do a global search for these issues...Global search across field definitions?
You can do the same search in the HTML version of the DDR.... just that the readability of the report is far tougher, the cross references are all manual following the data, and the searches are not categorical. A search in a text category in FMPerception has similar issues in results volume returned. And calculation content is NOT a FMPerception category, but a sidebar show and tell, so the search is a bit more convoluted.
A better text search might be for a LET string, which only exists in the calc dialog..???
My 2Ā¢ - FMPerception has been in my standard tool set since the day it was released (a follow up from FM_Xray). Pretty awesome and well worth the price of admission, if you are developing professionally. Unlike BaseElements and Inspector Pro, which have to import everything into their own FM instance, FMPerception is dynamic and very fast. I often run 2-3 XML DDRs a day during intense coding to apply FMPerception's tools.
2 Likes