by Matt Petrowsky
ScriptMaker - Making the most of it
Information about working with ScriptMaker
It was just a while back when I wrote an article about using ScriptMaker efficiently by componetizing your scripts. It's time that I elaborate on that issue.
One of the least used areas of FileMaker, when it comes to being a beginner, novice, or intermediate user, is ScriptMaker. Most of the time this is because it's misunderstood how easy ScriptMaker really is. For some, it seems like a daunting task of learning some new programming language to get the most power out of FileMaker. But this is just untrue. For the most part, ScriptMaker is better referred to as a *very* robust macro language.
You can't really consider it to be a programming language -- although you are programming FileMaker to do different tasks. In a programming language you do things like create and store variables with a one line string of syntax, you also have some very low level stuff like manipulating memory to consider. However, in FileMaker you set values to variables and manipulate data, the only difference is that you created the variables (fields) in the define fields area and don't have to worry about memory.
The most imporant aspect of ScriptMaker
When asking any avid FileMaker user what their favorite function of ScriptMaker is, the single overwhelming answer should be the "Perform Script" script step. The reason for this is that nothing could be tied together without that one step. The Perform Script script step is the glue that holds two scripts together. This is why I mentioned effective use of ScriptMaker by componetizing your scripts.
But what if you are just starting out or aren't yet that savvy with using ScriptMaker. There is a way to think about this tool that will help you get better: ScriptMaker is to FileMaker what your blood is to your body. It makes things work.
Making files talk to each other
When working with the Perform Script script step you need to know what happens, or what you can make happen when "calling" other scripts. There are all kinds of things that can be done and you need to keep in mind that you will rarely get a complex script, that really does some neat stuff, to work correctly on the first try. One of the most time-intensive aspects of creating a really powerful FileMaker database is that of debugging your scripts. The average amount of time in ScriptMaker consumes more than 85% of development efforts.
The Perform Script has a menu option at the bottom of the script selection list that offers External Script... It is this option that allows you to basically have the one script you are working in make a "call" to another script in another file.
It is this option that makes multiple file databases most powerful. You will almost always need to push data there or pull data here. The External Script option will allow you to do this.
Knowing what you should know
ScriptMaker can be considered married to calculations. This is also why ScriptMaker is so powerful. If you know most of the calculation functions, then know that you can use ScriptMaker to manipulate that data and create a very strong database. This is also another reason why ScriptMaker should not be so intimidating to some users. It's an important asset to your design.
You don't have to know every single calculation and what it does to effectively use ScriptMaker. I, myself, cannot make claims to knowing each and every function. In fact, there are some functions that I have *never* even used in my whole time with FileMaker.
Here is one of the many ways that you can think about ScriptMaker and how to use it with your FileMaker database. Starting with this article I will have a ongoing discussion of each of the areas listed below.
- ScriptMaker: The Basics
- ScriptMaker & Functions/Commands
- ScriptMaker & Data Manipulation/Calculations
- ScriptMaker & Navigation
- ScriptMaker & The User Interface
- ScriptMaker & The Module Method
ScriptMaker & Functions/Commands
Since ISO is focused more toward the intermediate to advanced level, with some beginner information, we will forego the basics for the magazine. I covered a little of the basics above.
A useful piece of knowledge is knowing what a tool can do for you and how to use it. This is where the functions and commands come in. The ones that you use will more than likely apply directly to the solution you are working on. Someone building a financial-related database will work more closely with the aggregate functions than someone who is going to provide more data manipulation.
Starting at the top of this list I'll go through each step and explain where you might use the script step and how it affects what you do. I'll only cover the first section of Control as found in the available steps listed in the steps of any script.
Perform Script - This step, as mentioned before, is the glue between all of your other steps. Using this script step is very important in all aspects of using ScriptMaker. Think of this script step as a request that you can make from a friend. You make the request as simple or complex as you want. But the friend has to know what to do and how to do it. For example, you have friend "A" that knows how to go to the first record in your database and then reserialize all numbers. Another friend, friend "B", knows how to sort your data and then check it off as being reviewed.
You're the boss and you send a memo asking friend "A" to do his stuff. You send a memo to friend "B" and ask him to do his stuff. This is basically how the Perform Script works. You use it to ask another script to do its stuff.
-------------------------------------------
Pause/Resume Script - For many users, a script is something that runs from start to finish and then stops. One of the reasons that you may want to pause a script is so that you can let the user enter some data. One of the more common uses of the pause/resume step is when you have a script that takes the user into a Find mode and then it will pause and wait for the user to enter their search criteria. Here is where the resume part of this step comes in handy. You can, in your database, create a layout that is used for searching and on that layout have a button labeled "Continue". The script step that you attach to the button using the Button... option under the Format menu is the pause/resume script step. Essentially what you have done is taken the user into a Find mode and paused for data entry. Now when the user clicks the "Continue" button the script is resumed and continues on its way.
-------------------------------------------
Exit Script - Why would you want to exit a script? Well, there are many instances that you may need to stop right in the middle of a script that is doing something. You would stop because of something that is based on a condition. The conditions can be controlled by data input from the user or any other piece of criteria.
This script step is most commonly going to be used in conjunction with an If script step. An example would be if you were to take the user into a Find mode and pause to wait for the user to enter data. Then when the user clicked the "Continue" button to resume the script your script would look at the value entered by the user and perform the find. If the search results found more than one record then you would Exit the script. But what if no records were found? You would then continue the script by saying that if no records were found that it should start the process over again by taking the user into Find mode so that they can start the process all over and enter some different criteria.
-------------------------------------------
Halt Script - What is the difference between Exit and Halt Script? Well, the biggest difference between these only becomes apparent when you are using many scripts within other scripts using the Perform Script script step. The Halt is a complete stop of all scripts, the Exit will just exit the script within which it is located. The difference has to do with whether you want the current script that is running to stop completely or you just want one of the scripts that you have "called" to exit at a certain point.
Example: you have a script called "My Script" and that script "calls" script "A". My Script takes the user into a Find mode and then pauses for the user to enter some data. When the user clicks a continue button that has an attached resume to it, the find is performed and the results are returned. If the results are that there is more than one record then My Script says Perform Script "A". Script "A" in turn says that it needs to Go To the first record and start Reserializing (renumbering) a number field. My Script also says to Perform Script "B" right after script "A". But what if the results of the search had already been done that particular day and you only wanted it to be done only once each day?
This is where the Halt comes to the rescue. Within script "B" you have some steps that have it look at the modification date of record number one. If the modification date is the same date as today then you are not supposed to reserialize the data. You just need to completely stop the process. There is no need to have My Script "call" script "B" to even run. This is where you put the Halt Script script step - inside of script "A".
The Halt Script script step is most useful when using branches of scripts that call other scripts.
-------------------------------------------
If - Without this one statement we might as well call it quits with FileMaker or any other programming language for that matter. The almighty conditional is what allows us to have FileMaker make decisions. If you don't know what a conditional is, then all you have to know to understand it is that it follows the same questions you ask in life, "What <if> this happens? Then what will happen?" Knowing how to use the If statement both in ScriptMaker and calculations is vital.
Using the If statement you are able to make decisions based on data, settings, the status of current fields, computer attributes or where the user is in a process of some sort.
A good example of using the If statement with concern to layouts is when you make the decision of which layout to show based on the user's monitor size. You can use the Status(CurrentScreenWidth) and Status(CurrentScreenHeight) to check the monitor size that is being used. If the current monitor being used is 640 pixels wide then you can use layout #1 otherwise (else) use layout #2.
-------------------------------------------
Else - The Else statement is used when your conditional If statement is not met. The Else can be thought of as the default of the If statement. In other words, if your If statement does not evaluate as true then what <else> should it do. It should do the Else part. Just remember this, if it's not this, then what else should it be. And you provide the else.
One of the tricks to using the else statement is to have it call another script. If, for example, you have an If statement and your condition is not met then you can run another script or some other sequence of script steps that include another script.
-------------------------------------------
Loop - Yet again we find all of the most powerful script steps within the Control area. Next to the If statement the Loop is one of the most powerful script steps in all of ScriptMaker. The Loop function will do exactly what its name says: it will loop through the series of steps between the Loop that starts it and the End Loop that finishes it.
Some of the more common loops used in FileMaker deal with cycling through a number of found records. You will find the Go To Record/Request/Page, with the [Exit after last] option checked, used with the Loop function often. Some of the other times you would use a loop are when you need to cycle through some data and put different pieces in different places.
One of the common controls when using a loop is to create what is called a counter. A counter usually comes in the form of a global number field. This is because you can set a value to the global number field and then either increment it or decrement it as you pass through the loop each time. When the global value hits a certain number you can "kick out" of a loop by using the Exit Loop If statement. For example, you set a global field named Counter to 50 and have a script step between the Loop and End Loop that says to Set Field ["Counter", "Counter - 1"]. Your "kick out" is the Exit Loop If ["Counter = 0"].
-------------------------------------------
Exit Loop If - This script step is used in conjunction with the Loop function. This is the step that serves as the "kick out" for the loop function.
Some of the more creative uses of the Loop and Exit Loop If include using these within a Find mode so that the user enters the correct search criteria or using the Status functions to make sure that certain Errors do not occur.
-------------------------------------------
End Loop - This is just the closing part of the Loop functions that starts a loop process. You will always have to have one End Loop for each Loop that occurs in a script.
-------------------------------------------
Allow User Abort - This script step came just in time with all of the power that was introduced in FileMaker 3.0. This step can basically be a life saver or can bring you to your knees. There are two modes of Allow User Abort. Off and On.
When the Allow User Abort is Off then the user cannot abort the script by using the key combination of Command-. (period) to cancel the script. This script step can get you in trouble if you use it within something that does not come to an end. For example, if you specified FileMaker to use an opening script that has the script step Close File in it and you also put the Allow User Abort [Off] in the script then you would essentially never be able to open the file.
On the opposite end you have the On. This basically allows the user to use the conventional abort methods of Command-. (period) or the ESC key to stop a script process.
-------------------------------------------
Set Error Capture - Like the Allow User Abort functions this one has two modes, off and on. When the error capture is turned on then you must do your own "trapping" of errors. It is called trapping because when you hit an error, like, for example, no records are returned after the user does a search, then you must do something with that error. You have trapped it and you must now skin it, pluck it or do whatever you would to a trapped error. You either have to take another course of action or tell the user that he/she hit an error and must do something about it.
The most heavily used script steps used with Set Error Capture are the If combined with the Status() functions as the conditions. There is a whole list of all of the errors that you can capture for. If, for example, you are tired of the error that is generated when you click cancel on a print dialog box that was generated from a script, and FileMaker says "Print could not complete. Do you wish to continue the current script? <Cancel> <Continue>" then you can trap this error by turning on the error capture.
-------------------------------------------
This completes only the first area of ScriptMaker. In future articles I will focus on the other areas of available steps in ScriptMaker.
## END ##