Lesson 1: The Data Viewer Watch Tab & Script Debugger Transcription The data viewer is useful for writing and debugging scripts and calculations. The data viewer is a built-in developer tool in FileMaker 17 – before version 17, you needed a copy of FileMaker Pro Advanced to use the Developer Tools. To turn on Developer Tools in your settings on a Mac, go to FM Pro Advanced → Preferences → General → Use Advanced Tools. On a Windows, go to Edit → Preferences → General → Use Advanced Tools. You should now see Tools in the top menu. Go to Tools → Data Viewer. There are 2 tabs – the Current tab and the Watch tab. Current tells you fields or variables in use by a script while it is running. Because of this, the current tab will usually be empty unless you’re running a script through the script debugger. Sometimes you’ll see global variables here, which are the ones with the double dollar signs, because they are independent of scripts. If we switch over to the Watch tab, you’ll likely see an empty window here as well, unless you’ve used the data viewer before. The Watch tab is used to monitor expressions, which are created manually by clicking the add button. They’ll remain in this list until you delete them. Expressions can be created to test long or complex calculations, or to watch variables’ end fields while running scripts or moving through records. To add an expression, click the Add button – this looks a lot like the calculation window that opens in other parts of FileMaker. The biggest difference is a Results section that shows you the results of your calculation instantly. The Automatically Evaluate checkbox automatically evaluates your expressions without needing to click the Evaluate button. We’ll write an expression to calculate a date that is two weeks from today. We’ll use FileMaker’s native function, Get Current Date and just add the number 14 to it, in order to produce a date that is two weeks from today. We’ll click Monitor to save it, and we can now view it in our list. The data viewer is context-based, which means that you will need to be sitting in the correct context in order to reference the correct field in your calculations. Otherwise, you will see an unrelated table error. We’re going to check to see if this date is past due by comparing it to the current date. Let’s start a new expression and we’ll choose the due date. We’ll check to see if it is less than the current date – if it is, we’ll see a 1 in the current result, meaning the calculation is true. Otherwise, we’ll see a 0 for false. Now that we’ve completed our expression, we’ll click monitor. We are looking to see if this date is less than the current date, which, as of this recording, is December 5th. We’ll flip through some records and watch the result change as the date changes. If we had written this to test a calculation before using it inside a script, we could simply copy this expression and paste it in our script wherever we need it. This is handy when writing long or complex calculations. It is much easier to test out your calculations here instead of testing it inside a script, which can be very tedious – we may be speaking from experience! Lesson 4: Data Viewer’s Current Tab & Script Debugger Transcription Data Viewer and Script Debugger are part of FileMaker’s built-in developer tools (see Lesson 1 to enable these tools). Go to Tools → Data Viewer. You will see Current and Watch tabs. The Current tab shows fields and variables in use by a script while the script is running. For this reason, it is often empty unless you are currently running a script through the Script Debugger. You might see global variables here (with the double $$) since they are independent of scripts. We’ll use the Current tab to run a script through the Script Debugger. Close the Data Viewer for now. To open the script workspace, go to Scripts in the top menu and click Script Workspace. We’ll run the script called Task.Add Related Record through the debugger. The task needs an additional assignee, which we can do by clicking this Add Assignee button. When this script is run, a window will open with a list of assignees in our database to choose from. This script will automatically omit anyone who has already been assigned. Additionally, I’d like to also omit people who are not currently active in the organization, in this case our App Tester assignee. If all goes well, we’ll be left with a list of assignees who are current and not currently assigned to the task, which will be Jennifer Johnson and John Smith. Let’s head back to the task detail so we can debug the script. To debug the script, we can access the Script Debugger two different ways. You can access the script directly from the script workspace by clicking the bug icon. This is pretty convenient for most scripts, provided its not reliant on script parameters being passed in via a button. In that case, you can use the second option, which is opening the Script Debugger from the Tools menu. Once it’s open, you can simply click the button to activate the script, or take any other action necessary that will activate a Script Trigger. Once that has happened, the script will automatically be opened within the Script Debugger. Let’s go over the different controls you can use to debug them. First up is the Edit Script button. Once a script is currently running, you can click this to open it up in the script workspace where you can then make changes. Once you save those changes, the script will automatically halt in the Script Debugger. Then you have the Run button. This will basically run your script through all the way to the end, or until a breakpoint is encountered. The Stop button will halt the script at any point. The Step Over control will execute the script one step at a time without entering subscripts. If the script step is a performed script, the Script Debugger won’t execute the subscript, but it will just proceed to the next line of the calling script. The Step Over control is very similar in that it will also execute the script one step at a time, but it will also enter and show steps in subscripts. Step Out will execute all script steps in the current script, and if the script is a subscript, it will return to the line right after the performed script step in the calling script. If the script is not a subscript, the step out command will cause the Script Debugger to execute all remaining scripts and subscripts until it encounters a breakpoint. The Set Next Step control allows you to manually select a script step in the currently running script and set it as the next script step to be processed. So, clicking this will not make that script step run. You will still need to use one of these other controls to actually execute the script, but it will set it as the next one to run and will skip any script steps in between what had been the current running script step and what you just assigned as the next one. The Enable or Disable Script triggers button allows you to temporarily disable or enable all Script Triggers in a file. When it’s highlighted in blue here, you can see that it’s currently enabled. If I were to select it again, it would be disabled. Last but not least is the Data Viewer button – this will open the data viewer for us. There are a few more things to mention about the Script Debugger – it has a Pause on Error checkbox that will pause scripts when errors are encountered. This works even when the Script Debugger is closed – it will automatically open the Script Debugger when an error is encountered. Here you’ll find the Call Stack, which will be a list of all scripts set to run. You can select a script in the Call Stack list to view that scripts’ steps in the display area. Now that we know how to use the controls, let’s go ahead and start our script to test them out. We’ll start by clicking the Add Assignee button. We now have our first script added to our Call Stack, and we can see that it is calling the correct script, Task.Add Related Record, and that no parameters were passed in. So to continue, I’m going to click the Step Into control. Also, let’s go ahead and open up our Data Viewer, so that we can watch what’s happening as we go through the script. You’ll notice there are a few fields that are showing up in our current tab. These are the fields that are being used in the script that’s currently running. To continue, we’ll click the Step Into step, and we can see that the parent primary key, which was supposed to take on the value of the tasks primary key, happened correctly. We now have a list of related keys, and another variable has been set to count the number of related records. In this case, it looks like there’s only one. Behind the Data Viewer here, that window that I mentioned earlier has opened, and by default, it’s showing all of the people in our Assignee table, including Some Buddy, App Tester, John Smith, and Jennifer Johnson. As we continue through the script, we should eventually get to a Found Set of just John Smith and Jennifer Johnson. The script will enter Find Mode, and it’s going to start a loop. Because we only have one related record, we should only have to look through this once. Basically, this script is doing a find for any current assignee of the task, and this will eventually be omitted from our found set. We’ll continue going and now that we’ve reached the end of our loop, we can scroll down and see that it’s about to perform the additional script steps that I’ve added. I’m also going to set the assignee’s active field to be null so that when we Perform Find, we are in a Found Set of the person who is not active, and the person who’s already assigned. As we click Step Into, it will now show only the omitted records, giving us the exact set we wanted. The next script step is Perform Script. Now if I wanted to step into the subscript, we could choose the Step Into control, but instead we’ll just let it run and click Step Over to be taken to the next line. But, as you can see in the background here, it appears that sort happened successfully. We’ll exit our script now, and it looks like it was a success!