Retrieve variables set in another script you performed

[Milerfake]

I was wondering how I would retrieve variables that I set in another script. I decided to split all my scripts up and one of them was to set all the field values as variables, so that when I created a new record and only needed some of information in those fields, I could set them individually by retrieving them from that script alone.

 

Kind regards

[Steven H. Blackwell]

Exit script with script results passing the variables as a compound parameter.  The Get(ScriptResult) command then can retrieve those.

 

Steven

[comment]

retrieve variables that I set in another script.

 

Please elaborate on how these scripts are wired to work together. In general, the scope of local $variables (single $ prefix) is limited to the script where they were created, and they cannot be accessed from outside.

[Justin Close]

I like Steven's answer the best, but other options include:  setting fields in a table (global fields probably make the most sense), or setting global variables ($$var, double dollar sign) in the called script, and then read those fields/variables in the calling script. 

 

But yeah, use 'Exit Script [Result]' and 'Get(Scriptresult)'. 

[Wim Decorte]

You most certainly do NOT want to set global variables in this case.  That's a big NO NO.  Variables should never live longer than they need to.  If you declare global variables for the sole purpose of passing some data back to the calling script you are in effect creating a variable that will live past the execution of the scripts.  It will persist until you close the file (your session).  So it may very well overwrite some other variable value that has some meaning somewhere else.

Now in your mind it may perfect sense but for another developer to step in and troubleshoot that is a huge red flag.

[Justin Close]

...If you declare global variables for the sole purpose of passing some data back to the calling script you are in effect creating a variable that will live past the execution of the scripts.  It will persist until you close the file (your session).  So it may very well overwrite some other variable value that has some meaning somewhere else...

 

 

I agree with all this; that is how they behave.  Slight clarification though:  they won't exactly 'always' live until you close the file: you can actively clear them to make them go away, but you do have to actively do it.

 

Yes, they may overwrite other variables, but that is true of any data: if you store it in the same place it is going to replace that data - global field, local field, or global variable.

 

I did suggest that he use the multiple parameter technique; it is completely insulated from all other interference.  But there are reasons to store temporary values for future use - you can't use a passed parameter for that.  Do you always use global fields for that, then?  But a global field has the same pitfalls as a global variable it seems: it can be overwritten.  Are there more specifics between the two that you can elaborate on?  Do you have instances where you do use global variables?

 

These are all capabilities and tools of the system; it's good to know how they work.  Yes, and when-to and when-not-to use them.

[Wim Decorte]

I decided to write a blog post on the topic:

http://www.soliantconsulting.com/blog/2014/01/all-variables-should-be-global-or-not

 

Your argument about overwriting data is valid, but only up to a point: when you write data (to a field in a record in a table) you typically are more aware that you are doing that and what the context is since you have to seek out the record first.  With variables that are out of scope you just write to them (or worse: read from them expecting that they have a certain value that has been changed since first declared).  Obviously if you are extremely diligent about keeping track of your variables you are going to be ok.  But the risk of "collision" is much greater, especially with multiple developers on the same project.

 

Sure there are reasons to store temporary stuff in global variables.

[comment]

The value of a $var can be used throughout the duration of any script (even when you declare it part of a calculation outside of a script!).

 

What do you mean by the sentence in parentheses?

[Wim Decorte]

When you declare a local variable ($variable) in a Let() in say the data viewer, or a field calculation, or a conditional format or chart calculation, any running script will have access to that value.  And that may be a bit unexpected.  Take this scenario for instance:

 

My script

 

Set Variable[ $variable ; 10 ]

Go to Layout[ someLayout ]

Set Field[ someField ; $variable ]

 

You'd expect "someField" to be set to 10.  But if there is anything on the layout (unstored calc, conditional format,...) that uses a Let() and also declares $variable then the Set Field will use the value set in the Let()

[comment]

any running script will have access to that value.

 

I don't think that is a complete description: the script will have access to that value only if the $variable was populated during the execution of script. In your example, if the unstored calc is re-evaluated as a result of going to the layout then yes, the $variable created at the beginning of the script will be overwritten. Otherwise there will be no collision between a $variable created say in Data Viewer and a script that uses a $variable with the same name.

[Wim Decorte]

I think we're saying the same thing fundamentally.

 

The last declaration of a variable always wins.

 

• If you declare $variable in data viewer and then run a script that sets $variable then the script's value wins
• If you run a script and set $variable and then something else is triggered that sets $variable, then that last value wins

 

The point I'm trying to convey is:

A lot events are not in our control (the calculation of unstored calcs, the data viewer refresh, evaluation of conditional formats or visibility calcs, charts,...), typically places with an calculation area where Let() can be used to declare $ and $$ variables out of scope.  These can fire in the  middle of our scripts if we are not careful.

 

So the "the script will have access to that value only if the $variable was populated during the execution of script." is a bigger risk than I see typically acknowledged.

[comment]

I think we're saying the same thing fundamentally.

 

I am not sure about that; I can't figure out if the difference is semantic or real. For example:

 

If you declare $variable in data viewer and then run a script that sets $variable then the script's value wins.

 

That's not how I would put it, and I think for a good reason. If you declare $variable in data viewer and then run a script that sets $variable, then the script's value overrides the previously declared value for the duration of the script. Once the script has exited, the $variable reverts to the value declared in data viewer.

 

In fact, a better way to put this is that each script has its own set of $variables (hence "local"). There is no - and cannot be -  collision between the local variables of a script and the local variables of another script, or the local variables of a 'no script running' state (what Ray called "script 0"). There can be a collision between local $variables declared by the script itself and local $variables declared during the execution of the script by other means.

[Wim Decorte]

 If you declare $variable in data viewer and then run a script that sets $variable, then the script's value overrides the previously declared value for the duration of the script. Once the script has exited, the $variable reverts to the value declared in data viewer.

 

 

Not automatically: only when the data viewer refreshes itself or you do it manually.

 

As to the rest: I'm ok with how you formulate it.

[comment]

Automatically, yes. Have a look at the attached file - it shows how the local variable is "overwritten" by a script, then "reverts" back to its non-script state.

 

RevertMyvar.fp7.zip

 

What really happens is that the entire set of local variables is put aside while a script runs. The script brings its own set of local variables that are in force only for the duration of the script. When the script exits, the suspended set is restored.

 

It's somewhat similar to installing a custom menu set; while the custom set is being used, the default set is put aside and can be retrieved at will.

[Wim Decorte]

We're not talking about the same thing here with the "automatically".

 

And to make sure: I fully agree with what you say and demonstrate in your demo file.  That's the "Script 0" concept.  That's a little too advanced for what I wanted to cover in the blog post.  The blog post is all about the core concept.

 

In my last reply we were talking specifically about declaring a variable through Let() in the data viewer and how that value refreshes.  The point I was trying to make there is that when you declare a variable in a Let() in the data viewer and then change the value in a script.  The variable does not return to its Data Viewer value (unless the Data Viewer declaration was the "script 0" declaration).  Only when you the Data Viewer entry is "pulled into view" will the variable be reset to the value shown in the data viewer.

 

 

 

 

[comment]

We're not talking about the same thing here with the "automatically".

 

Probably not, because I am still having trouble understanding the situation you describe:

 

when you declare a variable in a Let() in the data viewer and then change the value in a script.  The variable does not return to its Data Viewer value (unless the Data Viewer declaration was the "script 0" declaration).

 

I don't follow the chronological sequence of events here. Do you mean "declare a variable in a Let() in the data viewer" while the script is already running?

[Wim Decorte]

Ok, one more try then.  We're talking about a situation where nothing has been set in "script 0"

 

In your demo file:

 

1) run the script that sets the variable (don't do the first option to set the variable outside the script)

2) Test: $myVar will be "Bravo"

3) with the script paused, do the Let() in a Data Viewer as per my screenshot, close the Data Viewer Open

4) Test: $myVar will be "Wim"

5) Exit the script

6) Test: $myVar will be empty

 

In #12 I understood that you said that in 6) $myVar would automatically be reset to what the Data Viewer says it should be.  Whereas I said it would only do that if the Data Viewer entry was visible.

[comment]

Ok, that I can agree with.

 

As an aside, the data viewer is muddying the waters here, because testing the value of $myvar causes the data viewer to re-evaluate it (if the data viewer is open). So it's not like it's reverting to the pre-script value; it's re-declaring the same value anew.. This can be seen more clearly if you make the data viewer calc =

 

Let ( $myvar = Get (CurrentTimestamp) ; $myvar )

[Wim Decorte]

Good conversation, clarification and advanced info.  I've linked this thread in the comments on the blog.