|
|
Scripting Primer
|
Level: Beginner Version: FileMaker 15 Category: Scripting Tuesday, April 18, 2017 |
|
|
|
|
|
|
What is FileMaker Pro scripting? It can be defined as automation, a macro and even a programming language. FileMaker Pro scripting has elements of all these definitions. The original purpose of scripting was to automate the mundane task of printing a report. Since it repeats most of the items under the menus, it can also be considered a macro language. Yet, it is so much more! With logical branching, it can even be considered a programming language. The FileMaker Pro Script Workspace is a beautifully designed environment that enables you to create a solution as good as any commercial product on the market.
Nonetheless, learning 150 plus script steps and how they interact with each other is a daunting task. The first part of this guide aims to pare down this list in order to make the learning process easier. Scripts will be divided into three groups so you know which steps should be ignored, which are the most important and which ones are useful but easy to learn. Later, discussions about how to activate scripts, shortcuts, comments, the Script Debugger and the Data Viewer are discussed to further assist you in understanding additional areas of scripting for which you should focus your learning efforts. No actual scripts are discussed as this is just a primer. Think of it as an overview of what's possible or a tour of the scripting environment, aimed at getting you ready to write your first script. However, I'm sure even experienced scripters will encounter a few nuggets of truth.
The Good As mentioned, most script steps simply repeat menu items. However, there are quite a few script steps that perform tasks not possible with FileMaker menu items. For instance, Set Error Capture allows you to suppress FileMaker error messages and replace them with custom messages. Allow User Abort prevents users from canceling a script, is another good example of programming like features in the scripting environment. You should spend most of your time learning the script steps in the table below. Most of these script steps also incorporate calculations in their abilities, increasing their depth immensely (e.g. IF, Set Field and Go to Object). Some are just so useful in so many ways that scripting wouldn’t be the same without them.
It's not that the rest of the 150 plus script steps are unimportant. They just don't have as much depth. For instance, you may utilize the Go to Layout step in almost every script you create, but it doesn't do much more than switch layouts. While switching layout is very important for context, once you learn how to use it, there's not much else. Even when incorporating a calculated layout name or number, the formulas are fairly straightforward. On the other hand, the script steps listed above are so rich, you will spend a career learning how to use them.
The Bad There are also script steps that you should almost always avoid.
The most offensive script steps of them all are Copy and Cut because they destroy the contents of the clipboard. Imagine a user manually copying a text string from one area of your program and then clicking on a button to navigate to another area for the paste, only to find out the data he copied has been erased by your flagrant misuse of the Copy and Paste steps in your scripts. There are easy workarounds using Set Field and Set Variable that don’t destroy the clipboard. For now, never use Cut, Copy or Paste unless your button contains one of these words in the title.
Cut, Copy, Paste, Clear and all the “Insert” steps share another bad trait. Each one of these steps requires the target field to be present on the current layout. Marrying your script and layout is almost never a good idea, requiring you to remember when modifying a layout that a script references fields and can’t be removed. I have seen so many solutions over the years where amateur developers hide fields they don’t want users to see but need to copy or paste in a script. Then they modify the layout and accidentally delete the fields and break the script. Set Field and Set Variable are a much better combination as they don’t require the target field to be on the current layout, just that the context of the layout is correct.
SIDE NOTE: If you do need to use an "Insert" or other script step that requires the target field on the layout, but don't want to see the field on the layout, drag it to the right into the gray area of the layout. It won't show on the layout but will be accessible by a script.
New File, Recover File, Convert File and Save a Copy As steps are steps that users just don’t need. Even developers don’t need these steps since they can perform them manually. The only reason I can vaguely imagine the need for these steps is to make a single line script so the command can be invoked by a keyboard equivalent. But how often do you need to perform these steps that a shortcut would become useful.
All the "Open" script steps are worthless. Just trying to be honest. If you don't already know how to enter Manage Database, you shouldn't have a script doing the same thing. And users certainly don’t need to enter Manage Database, so what’s the point other than to increase the number of script steps for marketing purposes. Don’t get me wrong. I love FileMaker but these script steps aren’t very helpful to anyone.
The Ugly So much for my movie analogy ("The Good, the Bad and the Ugly" starring Clint Eastwood) fitting perfectly with the theme of this article. The rest of the script steps that have remained unmentioned aren't really ugly, they just don't have a lot of depth but, also aren't completely useless. They fit into an entirely different group that are highly useful but are very straightforward in their purpose. If a favorite script step of yours hasn’t been mentioned, that doesn’t mean it isn’t handy. There are many unmentioned script steps like Go To Layout, Go to Record, Enter Find Mode, Perform Find and many more which are the workhorses of FileMaker scripting. They are used in just about every script but don’t require that much knowledge to operate. However, if a favorite step of yours was mentioned, but in a bad light, it’s time to learn some new tricks.
Denouement Now that you know what scripts steps are important, which are easy to learn and which should be avoided, the task of learning the 150 plus script steps doesn't seem as frightening. Focus on the important steps and avoid the undesireable ones. It's that simple of a game plan. just keep studying scripts and writing your own and before you know it you will be proficient. It’s still a good idea to become familiar with every step available, just in case. I recommend reading the definitions in the FileMaker Help section to familiarize yourself with every step.
Activating Scripts There are quite a few methods for activating scripts. The most common approach is to attach a script to a button. However, there are many other methods. Some are obvious and others are esoteric. Some have been right in front of your face the entire time without you realizing they existed. While you may only use a fraction of these methods for initiating a script, it’s a good idea to understand the variety of methods available in case you ever have a special case scenario that requires an out-of-the-box solution.
Let’s focus in on the OnFirstWindowOpen script trigger available in File Options since it is a very common trigger to employ. An open script can setup your database in many ways including initializing global fields, navigating to the correct layout, setting the window size and much more. However, there are several circumstances in which an OnFirstWindowOpen Script will fail to run. The most important is when a file is opened by a related field or the Perform Script step. The reason is simple... performance. If the OnFirstWindowOpen Script runs whenever a related field opens an external file, the performance could be greatly degraded by the execution of the startup script. Therefore, it is important to anticipate when a file is needed and open it with the Open script step which will allow the OnFirstWindowOpen to perform.
Specifically, when a related file is opened via a related field on the current layout, the file is opened hidden but can be manually selected from the Window menu or displayed by a variety of script steps including Select Window, Go to Layout and Perform Script. As soon as the window displays, the delayed OnFirstWindowOpen Script will finally perform. This could cause several problems including improper setup of a newly opened file or the interruption of the script that displays the hidden file. Most solutions these days are a single file so there is not much concern but it is important to note this behavior.
Another mishap to avoid is over-triggering a layout. While I love script triggers, it is possible to love them too much. Too many script triggers firing on a single layout, combined with all the button driven scripting, can often cause conflicts. Before using a script trigger, make sure all other features in the FileMaker arsenal have been exhausted like auto-enter, validation and calculation fields. A script trigger should be the best choice for a solution, not just what seemed to work at the moment.
I rarely use scripts under the Scripts menu, especially in a client solution. First, I almost always employ Custom Menus so scripts under the Scripts menu disappear. Second, scripts under the menu can be run from any layout. Unlike a button driven script, they adopt the context of the layout at the time they are run. This may not matter for some scripts but others may require a specific starting layout. Yes, you can start a script off by navigating to the correct layout with the Go to Layout step. I prefer to keep my navigation scripts simple and have them just switch layouts. If a script needs to do something in another context then have the user navigate there first and then click another button.
I always forget about the play button in the Script Workspace. If you don't have a script attached to a button yet, this can be a handy way to test it out without adding it to the interface. If your script is modularized, broken into multiple scripts and connected via the Perform Script step, the play button can run a sub-script sans the parent script. This is a great way to test functionality without running the entire script. I don't use this feature very often but it has helped me immensely when I needed it.
There are many considerations when choosing an activation method for your script. These are just a few of the most common issues and examples. You'll have to explore the variety of script activation methods out there to become more familiar with them and their unique benefits. The key here is to be familiar with what is available in case it fits your scenario perfectly.
Script Workspace Shortcuts The Script Workspace dialog is fairly easy to navigate and control with a mouse. I'm more of a mouse guy than a keyboard wizard but the Script Workspace comes to life when you use the keyboard. In fact, the new Script Workspace was designed for complete keyboard manipulation. A script can literally be created with no mouse interaction. It may take you a while to get to full keyboard ability so using a hybrid of mouse and keyboard controls is fine. Just keep practicing and moving towards sole keyboard interaction and it will make creating scripts more efficient.
There are many more shortcuts for scripting, especially with the keyboard oriented Script Workspace introduced in FileMaker 14. The best way to find these keyboard equivalents is to look in FileMaker Help for Macintosh and Windows shortcuts. Learning these shortcuts will speed up your development significantly.
Comments Commenting scripts is almost always a good idea. Trying to remember the detailed functionality of a script six months later is always a challenge. Get in the practice of making comments as you write your scripts and not afterwards when the details are vague. Comments also benefit anyone adopting a FileMaker project so be kind to your fellow developer.
Comments come in all shapes and sizes. The first couple of lines of a script are often comprised of comments describing the script in general. Comments for a group project will contain the name of the developer who wrote the script along with edit dates and short descriptions of changes. If you are a sole developer, history comments are usually unnecessary but certainly not unwelcome.
Anytime a script step or set of steps is complex or unclear, create a comment. But, this is where many developers go overboard and describe every single step. It’s really unnecessary and makes the script harder to read. Just comment steps that require deciphering.
It’s also a good idea to hide comments inside attached calculation formulas to keep the flow of the script intact. For example, if a comment is needed for a Set Field step, consider using the calculation commenting features inside the calculation option rather than a separate Comment step. This keeps the script clutter down, often making it easier to read the script. Unless the comment is significant and needs to be prominent, a calculation is often sufficient and less obtrusive.
Another tip is to comment without entering any comment text. Just type the Enter or Return key and a blank space will be created. This will offset the code with white space, making the code standout. Sometimes that’s all you need. Even well chosen script names and folder names tell enough of a story that comments become unnecessary.
Script Debugger & Data Viewer In the good old days, there was no Script Debugger or Data Viewer. Debugging a script meant adding a Beep, Show Custom Dialog or Pause/Resume Script step in a conditional statement to see if the script reached a certain point. If you were really sophisticated, you would add a calculation formula to the Show Custom Dialog to see a result so you didn't have to cancel a script just to check the outcome.
In the case of the Data Viewer, there was no choice but to write a calculation in it’s final resting spot, making the process complex, especially if the calculation resided in a script. If you wanted to see the contents of a field when a script was paused, it had to be placed on the active layout, often requiring you to run the script several times because you realized more fields needed to be added to the layout. Often that field was forgotten and left on the layout, requiring an update to the solution. Ahhhh... those were the days!
Successful scripting doesn’t require the FileMaker Advanced Script Debugger or the Data Viewer. These two features don’t give you extra scripts steps or calculation functions. They just make scripting more efficient with the ability to slow down your script, see error messages, view variable contents, examine fields without placing them on a layout and construct formulas more easily on a pseudo scratch pad. I do highly recommend FileMaker Advanced for serious FileMaker developers but Pro will get the job done too. To be honest, there are two features in Advanced that can't be worked around in Pro and those are Custom Functions and Custom Menus. These are show stoppers, like not having the calculation engine or something crazy like that, but I do use them in most solutions I create.
The Script Debugger isn’t really difficult to master. I could go through all the different features one-by-one but that seems like something that can be done within a few minutes of using it. My mission here is to convince you to shell out the extra cash for a copy of FileMaker Advanced and incorporate the additional features into your workflow. Once you start scripting on a regular basis, you’ll realize how difficult it is to write a script perfectly the first time around and how easily the debugger reveals your errors. Simply by slowing down a script so you can view it one step at a time, errors that were once difficult to find jump out at you and smack you across the face. I kid you not!
Add the Data Viewer to the mix and you can see all the fields and variables referenced in your script without placing them on a layout under the Current tab. If you need to see a field that isn’t referenced in the currently running script, just add it to the Watch tab. While the Data Viewer can be used one it’s own, the combination of the Script Debugger and the Data Viewer is an unbeatable scripting duo.
Author: John Mark Osborne
jmo@filemakerpros.com
www.databasepros.com
This blog is completely free. Please support it by clicking on one of the advertisers at the left side of the window or becoming a patron. Thanks so much!
|
Comments:
|
|
Saurabh Das
|
03/24/2020
|
|
If there were any doubts in my mind regarding Scripting in FileMaker Pro, it has all been erased with this simple yet elaborate post. I like the fact that you have covered every aspect of Scripting, the good as well as the bad. This post is sure to educate the readers better about Scripting. Thank you also for sharing Script Workspace Shortcuts.
Response by: John Mark Osborne
|
03/26/2020
|
Glad you enjoyed the article. Happy FileMaking!
|
|
|
Saurabh Das
|
03/24/2020
|
|
This post is extremely useful. Reducing the total coding requirement can secure the systems. You have shared the whole process of creating step-by-step end-to-end database in such details that anyone can easily comprehend. The screenshots can help further to clarify any doubts that arise in the minds of the readers.
|
|
Mauricio Navarro
|
04/22/2017
|
|
Hello from sunny Costa Rica. I've been following you for over three years, and I appreciate your interest on spreading your knowledge. Can't afford your courses, though. I have not seen any article of yours about UI techniques, but for what I have read from other developers UI nowadays tend to be clean looking. I mention this because of the text on your logo, it uses ugly fonts. Guess you can do better even if it isn't a FM solution.
Response by: John Mark Osborne
|
04/25/2017
|
Everyone is entitled to an opinion. Hopefully the logo doesn't distract you too much from the content, which is the focus of this blog. Happy FileMaking!
|
|
|
Barry Ezell
|
04/19/2017
|
|
It would be good to have a course on the east coast in DC Area on scripting. I learned scripting in the early 2000s. I could learn a lot from better techniques with newer versions like 15.
Response by: John Mark Osborne
|
04/19/2017
|
I agree wholeheartedly. The only problem is classes are getting low enrollment right now due to the economy. That's why I'm concentrating on videos at the moment. You can see my video offerings listed down the left column of this web page. Thanks again for the feedback!
|
|
|
|
|