A few versions ago FileMaker added the ability to pass parameters to and receive parameters from scripts.
Script parameters opened up a raft of ways to simplify and improve code. My favourite is the ability to write scripts in such a way as to function regardless of where the calling button is located or the context a calling script has.
The simplest example is maybe the creation of a record and related children, for example an invoice. Historically in FileMaker you might create a script that takes you to the invoice screen, creates a new record and leaves you there to add the details in. If then you wanted to automatically create invoices from a job you would need another script. If you wanted to create an invoice from another area of the system then you would need another script.
Imagine after a while you want to add nominal codes to the invoice lines. Now you need to find every place in the system where invoice lines are created and add the relevant code in. Its all just going to get more messy from there.
The alternative approach is to write a script that creates an invoice. Then another script that creates an invoice line. Any information these scripts require can be passed in parameters and relevant details from the record creation process can be returned as script results.
Whenever you need to create an invoice you call the invoice script. The script returns you the value of the invoice it created as a result.
Creating invoice lines is done by calling the invoice line script with the invoice number as a parameter. Other parameters could include value, quantity, line item details etc. So to create a new invoice with lines you call the new invoice script which returns an invoice number. You then loop calling the invoice line script with the relevant parameters one of which will be the invoice number created by the invoice script.
The natural result of writing functional scripts is that you find some scripts simply do not seem to want to fit as functions. Thats not a big deal. In fact its expected; the scripts that seem to want to refuse to be functions are almost certainly those that are business logic based.
As you build a library of functions within a solution you will probably find your business logic scripts will increasingly become a list of perform script calls passing the relevant parameters and receiving the appropriate results.
There are, as always in FileMaker, a few little problems. First and foremost is passing multiple parameters. The approach I take is to simply pass a return delimited list. Then its relatively simple to use getvalue(get(scriptparameter); x) to get the relevant parameter (where x is the parameter name). My main reason for sticking with this approach is that it is simple, quick and tends to keep the code readable.
The alternative is to create a custom function that takes the get (scriptparameter) list and recursively loops through the list entering the values into variables. This can be combined with a clever script naming convention to define the variable names. For example if you name your scripts ScriptName[parameter 1; parameter 2; parameter x………]. Your custom function can take the values between the square brackets, create a return delimited list then effectively you can treat these two lists as a pair of matched arrays within your custom function. The biggest disadvantage of this is the length of script names; you can quickly hit the 100 character limit.
Hopefully this will create a few ideas on ways to move FileMaker scripting to a more functional basis and allow you to build more reusable code.