Passing parameter to subscript, or updating variable mid-script process puzzle I can't solve: file and screenshot attached.

[dmontano]

Hi all,

I can not figure out how to pass a parameter to a subscript to be used in the filename when exporting records to excel if a user selection in a custom dialog window changes the found count of records.

The problem is not specific to the export to "Excel", but rather my inability to get the updated "found count" into the exported filename. So, in this aspect, I consider this a variable that needs to update before it is processed by the variable calculation that "makes" the filename.

I know my problem lies in the "second" level of branching that can occur if User selects an Export button when (found count = 0) which I think would be rare, but possible. I also understand that I could get around this challenge by getting rid of the third button "Export All" found in the Custom Dialog I present to User: I consider this the "second" level of branching.

Since I am choosing to NOT circumvent the challenge this poses to me, and in spite of the fact that what I am trying to do might be "convoluted", I am planting a flag in the ground in order to learn how to pass parameters to subscripts, or to update a variable as a script runs based on User input or selection via custom dialog.

I have practiced "avoidance" of FileMaker aspects long enough and trying to become more "learned", lol.

So, if anyone is brave enough to sludge through what I am presenting (screenshots and stripped down FileMaker file) in order to see where I have failed and can provide insight - I appreciate it. I have done my best to communicate clearly, but know this is an art form I am not gifted with.

Thanks in advance.

script_problem.fmp12

[comment]

This is a little too much to take in all at once. Consider simplifying the issue and/or breaking it up to individual points.

Speaking in general, the script parameter remains constant throughout the life of the script, while a script variable can be defined and redefined at any point. If you want to export a file using a variable as the file's name, and the file's name is supposed to contain the count of exported records, then of course you will want to define that variable as close to the export as possible and not before any event that can modify the current found set.

HTH.

 

Edited July 25 by comment

[dmontano]

On 7/24/2025 at 9:44 PM, comment said:

This is a little too much to take in all at once. Consider simplifying the issue and/or breaking it up to individual points.

Hi Comment - thanks.

Sorry about the overload: I tried to simplify, lol.  I know for sure that I have over-complicated this while trying to simplify it: definition of oxymoron?

I will dive back into this and see if I can break this down into digestible pieces.

 

On 7/24/2025 at 9:44 PM, comment said:

while a script variable can be defined and redefined at any point

Ok, this is good to know. This means that I can define a "first instance" variable for the "found count" to begin with, and redefined this variable differently based on another selection a User makes during the scripts execution, for example, the custom dialog I am presenting to User allows them to make a "second" selection.

 

On 7/24/2025 at 9:44 PM, comment said:

the script parameter remains constant throughout the life of the script

Is it safe for me to assume that a script parameter passed into a script (from a button, for example) does NOT get passed into a subscript unless we specifically configure the script to pass to subscript? And a subscript would need to be configure to "receive" the parameter from its parent script?

 

I hope to put some effort into this tonight - thanks again.

[comment]

10 minutes ago, dmontano said:

Is it safe for me to assume that a script parameter passed into a script (from a button, for example) does NOT get passed into a subscript unless we specifically configure the script to pass to subscript?

Yes. Every script has its own parameter that must be passed to it explicitly when the script is called. To pass its own parameter to a subscript, the calling script would need to do:

Perform Script [ “abc”; Parameter: Get ( ScriptParameter ) ]

Keep in mind that a subscript does not "know" it's a subscript. It runs independently and does not inherit anything from the calling script.

 

[dmontano]

On 7/25/2025 at 10:41 PM, comment said:

Yes. Every script has its own parameter that must be passed to it explicitly when the script is called. To pass its own parameter to a subscript, the calling script would need to do:

Perform Script [ “abc”; Parameter: Get ( ScriptParameter ) ]

 

 

Okay - after much effort I got what I wanted to work with your help - thank you Comment!

Again, I'm brand new to JSON, still a newbie in passing a script parameter, brand new to passing multiple parameters, and brand new to passing multiple parameters to a subscript.....whew! It's been quite the challenge and I'm sure I can improve and refine this as I gain a bit more experience.

With all that said, can I get any validation/verification feedback if what I have done below is GOOD or BAD practice? Even though I got my script to work, it does not mean what I did is a valid/proper way of doing so.

1. I used JSON to pass multiple bits of "information" into a script to be used throughout the script. I "converted" the JSON "bits" into variables for the script to utilize. 

2. The script then "calls" upon a subscript in various If/Else situations. Here, I need to once again pass parameters to the subscript.

3. I used JSON once again to pass the parameters to be used by the subscript. However, what I noticed that is different in this "second" JSON data set is I am using the local variables defined in the "parent" script itself. I think this works because this second parameter "set of information" is obtained FROM the locals variables while still operating within the parent script and "saved" as the parameter and "sent" to the subscript for its use? 

See screenshots of the two different JSON "objects?" that I created: one for the "parent" script, and one for the "child" subscript. 

If this is considered "good", I am going to consider this arduous lesson over and I can lean on this method moving forward to pass bits of data to scripts/subscripts. If it's bad I need to correct it before I build a bad habit. 

Any feedback appreciated - thank you.

 

JSON FOR "PARENT" SCRIPT

 

JSON FOR "CHILD" SUBSCRIPT

[comment]

I still don't fully follow your plot, so I will again make only a few general remarks:

JSON is a good way to pass multiple values in a script parameter. Another option is to stack them in a return-separated list. JSON offers several advantages over such list:

• values can contain carriage returns;
• values are named;
• values can be empty;
• numeric values retain their data type (alas, this does not extend to date, time and timestamp values).

OTOH, JSON takes a little more time and effort to put together and take apart - both for the programmer and for the executing hardware.
 

Extracting individual values into variables makes sense - if you're going to use them more than once. Otherwise you're just wasting CPU cycles and memory space. There are some that would justify such waste for the sake of code readability. To them I say that ... wait for it ...

Spoiler

that's what comments are for. 🙂

 

Edited July 29 by comment

[Ocean West]

you can always use $$variables if you clean them up or use named buckets $var[rep]

[dmontano]

1 hour ago, comment said:

To them I say that ... wait for it ...

Quite clever what ya did there! lol.

 

1 hour ago, comment said:

I still don't fully follow your plot

And most of the time I can't follow my own plot! 

 

With that said…

I believe I'm beginning to see what parameters and variables are; why they are used; how and why JSON is a viable and perhaps preferable way to exchange data for some. I greatly appreciate the times you have helped me out - even when I probably made no sense.

Thank you!

[dmontano]

3 minutes ago, Ocean West said:

you can always use $$variables

Hi Stephen,

Thanks! I was beginning to see that as a possibility. I'm still learning $$ global variables and $ local variables. Often times I try to translate these concepts in ways that I can "understand" or "relate" to.

My current view:

$$ global variables in my mind are "SESSION memory blocks": they last through a Users "session". Once logged off - poof, they're gone. So....these need to be managed by either setting them at the appropriate time with the understanding they stick around until the session is over, or until we "clear" them out explicitly.

$ local variables in my mind are specific "TASK memory blocks": once the task they are called upon is completed - poof, they too are gone.

I think good candidate terms for these two concepts could have been: $$_session_variable, and "$_task_variable".

But, then again, I may find that view is flawed!

[comment]

1 hour ago, dmontano said:

I think good candidate terms for these two concepts could have been: $$_session_variable, and "$_task_variable".

I believe that a better term for local variables would be script variables since that "task" you refer to is actually the script in which they are defined. Now, what happens if you define a local variable while no script is running? Such variable is similar to a global variable in that it persists until the end of the session - except that its existence is suspended while any script is running (Dr Ray Cologon coined the concept of "script zero" in this context).

Keep in mind that there is a third kind of variables, the unprefixed ones defined in a Let() or While() function, whose scope is limited to the calculation performed by the function.