In this series, “Learn FileMaker Like A Boss“, we’re exploring those techniques, mindsets, and tools that make us a better developer. I’m starting the series with topics based on my own discoveries during my formative FileMaker years. In this post, we will take a look at the FileMaker Script Debugger.

The FileMaker Script Debugger (found in the Tools menu of FileMaker Pro Advanced ) is a developer’s essential tool for testing a script to see if it works as described in the use case. We can watch a script step-by-step as it runs. We can control it precisely, running through the whole script or just parts of it as we test it out.

The FileMaker Script Debugger

The FileMaker Script Debugger contains a lot of useful tools

The many buttons and parts to this debugger are shown in the picture, and FileMaker’s help has a complete description of each.

Narrow Our View

What we are going to do is focus on using the buttons labeled as 4, 5, 6, and 7. Though FileMaker’s help talks about these, I’m going to put it into practical terms how these can be used. So as I go thru this description, refer back to this diagram.

The focus of this blog post

A set of buttons that are often underused.

All You Can Do

Once the FileMaker Script Debugger is activated and holds the script in its window, you have very fine control over the progress of the script.
We can:
  • Perform each step in sequence
  • Perform many steps at once
  • Perform an entire subscript without having to view that script’s steps
  • Skip over a certain part of the script
  • Back up

Let’s discuss each one of these in detail. The video that accompanies this post will show this clearly as well.

Perform each step in sequence

Button 5, called “Step into” performs each executable step in sequence. Clicking that button (or its shortcut F6) performs the step the Active indicator is on ( label 10) and pauses at the next step. If this button is clicked on a subscript, that script’s steps will display in the debugger and the active indicator will be at the first executable step in this subscript. This button is very handy to watch every step in every script being called. I tend to use this one more.

Perform many steps at once

Button 6, called “Step Out” simply performs all the steps in the current script until it reaches a breakpoint (label 11) or the end of the script. This could be in the parent script or in a subscript. If in a subscript and there are no breakpoints, the action will return to the next line of the parent script

Perform an entire subscript without having to view the steps

Button 4 is one I fail to use often, but am using it more. “Step Over” does roughly the same as button 5: it performs each script step in sequence, and it performs an entire subscript up to a break-point. Clicking this button, we will not see the subscript’s steps, up until a break-point in the subscript.

Skip over a certain part of the script or Back up

This action and the next one are done by the same button, button 7, called “Set Next Step”. This is an amazing command that I always forget about. A former colleague, Agnes Riley, reminded me of it. This button allows you to pick the next step to be performed. You highlight the step you wish to go to and press this button. The active indicator will go that step but will not perform it.

How it is used

With this button, you can do the following:
  1. Go back to the beginning of the script.
  2. Skip an entire section of the script
  3. Go into some logic that is not true in the normal course of the script.

This action requires some thought and care. In FileMaker, context is king, so a script step needs the right context to be able to perform the expected action. And it might not make sense to skip an entire part of the script, but if it can be done safely, then this button helps with that. But this is extremely useful to test and retest a part of the script. I’m finding this more and more useful.

The Script Debugger In the Real World

In a recent demo, I wrote a script to show an explanation card window depending on the script parameter passed into it. It is a simple script, but it can illustrate my purposes well.
A script to debug

Real-life Uses

Backup and Start Over

I start to test this script, and so I press button 5, “Step Into” from the Script Workspace. I notice that the debugger isn’t going into any of the If statements, and realize it is because I forgot to run this from the button which passes in the parameter. Rather than stopping the script, I can add the $param variable in the data viewer (see next post), setting the value to “part1” and then go back to line 11. I highlight that line and then press “Set Next Step” (button 7). This takes the active indicator back to line 11 and allows me to run through and finish the script.

Go inside

Next, I finish testing the logic inside the IF statement at line 15. I get to line 27 and, before I stop this script, I test line 19. Even though $param = “part1” I can use the “Set Next Step” button to go inside the lF statement at line 18. So I highlight line 19 and press “Set Next Step”.

Skip a Subscript

Again I run the script , debugging it from the button with the “Solution” parameter so that line 21 will be true. It opens the card window on line 22. I next press “Step Over” (button 4) and the subscript is fully performed. That is useful because I don’t need to test that subscript.

Test A Subscript

I decide to test the subscript on line 23. I debug the script with the “solution” as the parameter and then, on line 23, press “Step Into”. This opens up the subscript in the debugger (I can see the names of the two scripts in the call stack, label 13). I view this subscript and decide it doesn’t need to be stepped thru line by line, so I press “Step Out” (button 6). This fully-performs this subscript and takes me back to the parent script.

 Using FileMaker Script Debugger Completely

I personally am using these buttons of the FileMaker Script Debugger more and more every day. I find them extremely valuable in testing. Their functions give me complete control over a script’s run during testing. I can’t imagine testing a complex script with out the power of the FileMaker Script Debugger.

Many of us FileMaker developers stumbled into the platform. We discovered it one day on our computer or were given a copy of it. We found FileMaker to be useful to rapidly develop a custom app for our personal or business needs, and so we invested time into learning it. Our evenings and weekends were spent on such places as lynda.com, youtube.com, the FileMaker Community, and other places where we could begin to understand how to use the program.

Along the way we picked up techniques that may or may not be the best technique for a given situation. We also may not have become aware of all the tools a developer has to better develop, test, and analyze.

If that is you, stay tuned. In this series of posts, we will explore what it means to learn FileMaker like a boss as we develop the techniques and flesh out mindsets we all should have.

My Stumbling Story . . .

I am a former teacher, teaching for 15 years, in grades 2 through 7. About year 11, I stumbled into FileMaker in a school that used the application simply to print paychecks for students. Though the administrator was the only one to use it, I became fascinated with the app and begged to help out with the development. I did the usual things described above and developed a pretty good system for my school: for the teachers, administrators, and secretarial staff. It expanded to three schools and 100 people using it.

A few years into my development, I stumbled upon parts of the platform that I had never used. I started to learn FileMaker more like a boss, and now those tools and concepts are essential to daily work. I look back on the very clear events and wonder how did I go so long without using, for example, the Script Debugger (I really did spend about 2 years NOT using that thing)

The years have paid off, and I feel like gained my footing in my development. I’ve worked hard, have struggled with learning techniques, and have learned from the community and some of the best (and possibly award-winning) developers. Everyday I regain more of my footing.

Let’s Learn FileMaker Like a Boss

  • learn great techniques quicker
  • understand the essential concepts of FileMaker
  • use all the tools available for the entire platform
Learn FileMaker

These goals are here because I discovered these items ‘late’ in my development learning. We are going to explore how to become a FileMaker Boss! in this series. We’ll start with three items I discovered for the first time well into my development career. We will discuss such things as the Script Debugger, the Data Viewer, the Developer tools and other tools.  Finally, we will explore such concepts as relationships and transactions. We will describe techniques such as related value lists or data visualization. And all the while, we will be a FileMaker Boss!

The Topics

We will cover many topics, and those will be listed here. Check back for a new topic. The first three topics come directly from my own learning back in my beginner days. Those three are:

 

See yah soon as we Learn FileMaker Like a Boss.

FileMaker developers work to control a record's life cycle, but FileMaker Drag and Drop can subvert that entire process. We look at a possible solution.

In a typical day, a FileMaker user is interested in storing information in a custom app and then reporting out on that data in many different ways. A record, at the very heart of FileMaker, accomplishes this need. Here, data is entered and stored, and from this object, information is retrieved. One way data is entered is through FileMaker Drag and Drop, and therein lies a problem.

The Life Cycle

A record has a life cycle. It is created, edited, and committed to the file. Sometimes it is deleted. This cycle happens over and over. A record may go through many edits and commits in its life.

FileMaker drag and drop

A record’s life cycle

A primary job of FileMaker developers is to control that record life cycle. We set up strict controls about when a record can be created, edited, and deleted. We build logic to ensure a record has the correct type of information, and we work to ensure that the record is committed with integrity.

Like a vampire or a walker, however, there’s a user experience piece of FileMaker that is completely outside this life cycle and disrupts how a record is manipulated and then committed. That is the Drag and Drop.

FileMaker Drag and Drop: the Gotchas

FileMaker drag and drop is a great feature for fast data entry. This feature is commonly used for container fields and PDFs or pictures, but it can also be used to drag text data to a field. And that action is the disruption. When dragging data from another source into FileMaker, a user is almost completely subverting the record’s carefully structured life cycle, and thus the unexpected can happen.

Here’s a possible scenario: The user drags a text block from a website or email. She wants to save the text of an article or the current price of an item. The user simply highlights the text on the web page and clicks on it. Holding the mouse down, she drags the text over to the open empty and inactive field on the layout. Finally, she lets the mouse go and the text fills the field.

To the user, all is good, but under the hood, all sorts of unexpected things are happening:

The record is never opened. Or is it?

Normally when I type in a field, the record opens. FileMaker holds this record open for all edits. This doesn’t happen in a FileMaker drag and drop scenario. The data viewer, when watching the function Get(RecordOpenState), does not update from zero. Practically it may have opened, but the problem is that we cannot get to the open state of the record.

The record is never committed.

Well, I take that back a bit. Yes. It is committed because the data is stored in the field and record. Like the open state, we cannot get to the moment before the record is committed.

The modification count goes up

The result of the function Get ( RecordModificationCount) in the data viewer, increments by one each time.

Object script triggers do not run at all or properly

Mislav Kos and Wim Decorte at Soliant Consulting have a great rundown of all the script triggers and when they happen. The script trigger sequence, however it breaks down in a drag/drop scenario:

  • onObjectModify does run, but it runs after the record has already been committed (or the record has been closed).
  • The rest of the triggers do not run at all, no matter if they were meant to be a pre- or a post- trigger.

These facts present many problems for the developer. We are not able to control the life cycle of the record. We don’t get to capture when a record is open or before it is committed. Our lack of control over these means we cannot rely on script triggers to check field data for validation or for anything else we might do.

The Solutions

We can’t allow users to enter data without going through the proper business logic. So I can think of two solutions: either disallow drag and drop or highly control when a user can enter data into a record by any means they wish.

Disallow it

The first method is easier said than done. FileMaker Drag and Drop a preference in the app on each user’s machine. It is NOT specific to the file. So a developer or IT person would have to turn this off for every user. And of course, it can be turned on again in the preferences menu by a savvy user.

The Drag & Drop functionality can be turned off via the app preferences.

It would be awful to have to update this for each user

Disable it

The second method holds more promise: As a developer I might want to control when a user can enter data. I would have a separate data-entry layout and scripting to open a record and then check to make sure the record can be locked. When finished, the user would click a button that runs a script that checks various validations and allows the record to be committed or causes it to be reverted. Controlling the life cycle of the record means I could allow drag and drop.

Disallow it (Again)

Going back to method one, there is a way to disallow FileMaker Drag and Drop for all fields in a table without resorting to visiting each machine to turn off the app preference. The technique consists of a nondescript little field (text or number type) in the table where we want to prevent inadvertent drag and drop. I named my field “zz_ValidationField” so it sorts to the bottom of the field list. I’ve learned this from wise people: sort fields that do not contain data to the bottom.

On this field, I added validation in this manner:

  • The “Allow user to override during data entry” is unchecked.
  • The Validation can happen either “Always” or “Only during data entry”.
A validation of the field

Data Validation for my zz_ValidationField

  • Validation by calculation is used. Inside this is the function Get(RecordOpenState).
Validate using Get ( RecordOpenState)

The field’s calculation

  • Uncheck the “Validate only if field has been modified” checkbox at the bottom left.

Explanation

This setup simply prevents drag and drop from happening when the record is not previously open.  This field’s validation will fail if the record is not open ( Get ( RecordOpenState) = 0 ) and thus will not let the data be saved. The custom message doesn’t come up since the record wasn’t open in the first place.

Conversely, if the user opens the record  (Get (RecordOpenState) > 0 ) via scripting or clicking in any field and then drags and drops, the validation will allow the drag-drop to happen as normal.

As FileMaker developers, we have to control every aspect of our custom app so that we can ensure data integrity. The FileMaker Drag and Drop experience, dragging text blocks or PDFs gets around our control unless we take an extra step to ensure that users don’t get carte blanche in adding data to the file.

Download Demo File

FMPerception, the Fastest FileMaker Database Analysis Tool is even faster now. Version 16.0.7 brings some performance improvements to a couple of key areas as well as some much requested small enhancements. Take it for a spin and find our why FMPerception changes your game.

 Highlights

  • The Script Call Chain Diagram and the Layout Object Queries are faster, especially on large multifile systems.
  • Export, email and save your Report Cards and Script Call Chain diagrams. This was one of the most requested features on the list.
  • Global Variables now respects case. This means you can use FMPerception to find $$Vars that have different cases and clean them up.

See below for the full list of changes.

All Changes

Mac and Windows Changes:

  • Performance increases:
    • Script Call Chain diagrams are now much faster to display, especially in large, multi-file systems.
    • Layout Objects (flat) is now faster to display, especially in large, multi-file systems.
    • Huge thanks to Mark Jockin and his team for access to their DDR, which made wonderful test data for illustrating the problem.
  • Added a menu option to export the contents of the results web view. Now you can export, email and save your Report Cards and Script Call Chain diagrams. A couple of notes:
    • While tooltips and other mouse-over effects still work, clicking on elements won’t drill into them anymore. Those hyperlinks require that the URL be clicked from inside FMPerception
    • Because of the embedded engine that FMPerception uses, these exports will likely view best from Safari on macOS and Edge on Windows. If you are using other platforms or other browsers, your mileage may vary. Let me know if you have any issues.
    • In the short term, this functionality will allow you to use your browser to print or PDF the documents until such time as FMPerception supports printing natively.
    • There’s a known bug in the macOS implementation of the Script Call Chain diagram. If you open the exported HTML document in Safari and then expand the browser window, the boundaries of the diagram will not also expand. Short term solution: refresh the page once you’ve resized the browser window.
    • This one was requested so many times, I’ve lost track of who asked first. Sorry.
  • The Global Variables list now respects case.
    • Previously, all global variables in the global variables list were displayed in all lowercase.
    • Now, FMPerception groups all global variables ignoring case (as FileMaker does internally), but then displays the Global Variable by its most common capitalization pattern.
    • If the global variable is referenced using variations in case, the ‘Case Variants’ column will display all variants for that global variable (including, in parentheses, the number of times that variant was used). All variants will be displayed in order from most common to least common.
    • A line was added to the report card to indicate how many global variables have been references using inconsistent case.
    • This one also was requested so many times, I’ve lost track of who asked first.
  • Numerous typos were fixed in the Report Card, including a couple of 1/x math errors and a division error that caused the display of potentially very large percentages.

Huge thanks to Chiyoko Yoshida for the following:

  • Table Occurrences based off of Tables which have been deleted (and Layouts based upon those TOs) will provide better documentation in the detail sidebar about what elements are missing and why there are blanks in the results table.

Huge thanks to John Renfrew for the following:

  • When the contents of a script are displaying in the details sidebar, the formatting of blank script comment lines was subtly adjusted to make them more consistent with actual functional lines, making them easier to parse.

Huge thanks to Todd Geist for the following:

  • The JSON constant “functions” that specify node/property type were appearing as plugin functions. They now appear properly as FileMaker Pro standard functions

Mac-Only Changes:

  • The FMP ID column for table occurrences no longer uses a comma separator.
  • There were spots in the report card where the HTML used to format the text became visible. This has been fixed.

And finally, my apologies: The new Diff tool has taken quite a bit longer than anticipated. It’s still on it’s way.

http://youtu.be/mOhiXuZlhK8 Searching FileMaker Script Parameters FMPerception, the fastest FileMaker analysis tool available, makes it easy to find everything you have passed as a FileMaker Script Parameter using the built-in Calculation Analysis.  Watch the video for more info. Free trial availabl

Searching FileMaker Script Parameters

FMPerception, the fastest FileMaker analysis tool available, makes it easy to find everything you have passed as a FileMaker Script Parameter using the built-in Calculation Analysis.  Watch the video for more info.

Free trial available!

Have you ever deleted a script by mistake?

It happens. You’re moving quickly, jammin’ on your favorite FileMaker custom app. Laying down some insane custom business logic in the form of one awesome, totally badass FileMaker Script. Then you notice that other script. The one you need to get rid of. No time like the present. So you pop over to it, hit “delete”, crush the popup confirmation before you have time to read it and… Whoops, something went very wrong!

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!

You deleted the wrong script.  Your awesome, badass script with the insane logic is nothing but a memory. There is no undo. It’s gone. It’s not in the backup because you were just working on it.  It’s too new.  You are totally f#%@ed! You weep, you rage, you even try mediation. Nothing works. The script is still gone.

Then you remember. “Wait I just made a fresh DDR for FMPerception“. A smile creeps across your face. Yeah, you’re gonna be OK.  FMPerception is going to save your butt.

True Story

The above scenario happened to me this week. I deleted the wrong script. For a moment, it was bad. But then I remembered that FMPerception had the script. I could easily restore it, and reconnect it the other scripts that were using it. Just 2 minutes later I was done.

Phew!  Watch the video above for exactly how to recover a deleted script using FMPerception.

Need For Speed

FMPerception is so fast that it doesn’t get in the way of your workflow. As a result, you’ll use it all the time. You will be much more likely to have a recent analysis than if you are using an analysis tool that forces you to wait minutes or hours. Most FMPerception users know all about that, but what they might not know is that your analysis is also a backup, and can be used to restore code that you deleted or broken. And that can save your butt!

 

 

The San Diego FileMaker User Group is meeting Monday, October 16th at 5:30 PM at our office (address below). There will be pizza, other appetizers, beer, and soft drinks available. We’ll have some time to mingle a bit before the presentations begin. If you are in the area and you use FileMaker Pro or are interested in learning about what FileMaker Pro can do, please come by.

Topics

We are continuing our exploration of the new features in FileMaker 16 and how they change how you might design a FileMaker Custom app. We have a couple of topics on tap, but there is also some time for general Q and A.

LiveCode for FileMaker

Presented by Kevin Miller, CEO of LiveCode

LiveCode for FM brings the world’s only native app building platform for everyone to FileMaker. Drag-drop to create a full user interface experience, include rich graphics and multimedia, write code in English to crunch data from any source, or integrate your FileMaker app with the operating system or web APIs. The combination of LiveCode and FileMaker brings infinite possibilities to your FileMaker apps.

Error Trapping

Presented by Todd Geist

Let’s face it. Bad things happen. When that happens in your Custom FileMaker Application you want to make sure you catch and handle those errors in a graceful way.  The first part of that strategy is trapping errors in your script. We’ll take a look at some simple Error Trapping strategies that can use to make your FileMaker Applications better able to handle the unexpected.  We’ll see how FileMaker 16’s Native JSON function once again prove to be critical in how we solve this problem.

Server Side PDF Generation

Presented by Dave Graham

FileMaker 16 brings with it the ability to generate PDFs on the server. We’ll take a look at this new feature and how it can be used with Server-Side Scripting and Web Direct. You’ll see how you can email beautiful PDF reports from the server on a schedule without having to run a robot machine. We’ll also see exactly how to make this work on Web Direct.

Location

Geist Interactive, San Diego
1855 1st Street, San Diego, CA 92101

Meetup Group

Check out our Meetup Group. Join up if you’d like to get notified when we the meetings are happening.


San Diego FileMaker Pro User Group

San Diego, CA
28 Members

This group is for anyone interested in developing or deploying FileMaker solutions. Developers of all skill levels are welcome. Customers, potential customers and end-users lo…

Next Meetup

October Meeting

Monday, Oct 16, 2017, 5:30 PM
10 Attending

Check out this Meetup Group →

With the release of FileMaker 16 and native JSON functions, the ability to create a testable solution has been vastly improved. In this blog post, I will walk you through a simple example of what testing is, and how it can improve your solutions. Most developers have had situations where they need t

With the release of FileMaker 16 and native JSON functions, the ability to create a testable solution has been vastly improved. In this blog post, I will walk you through a simple example of what testing is, and how it can improve your solutions. Most developers have had situations where they need to alter some existing logic, and are concerned that they might alter something with unforeseen consequences. Wouldn’t it be nice if you could ensure that your changes didn’t break existing code? Welcome to FileMaker Testing.

Automated Software Testing

Software testing has a lot of different variations and buzzwords associated with it. You’ll hear all sorts of phrases and acronyms thrown about like TDD, BDD, Unit Testing, Regression Testing, etc. It’s worth a learning a little something about these at some point. But at the heart of all of them is a simple concept; write some code to automatically test some other code.  If you do, your code will be less fragile, and easier to maintain.

What is FileMaker Testing?

A test is a FileMaker just script used to ensure that other scripts are working properly. Tests ensure that scripts are not only accomplishing their goal but also producing the desired result when they fail. While there are many ways to perform FileMaker testing, we test using the following assumptions:

  1. Each script to be tested accepts & returns JSON as a parameter
  2. We will be using custom functions for handling errors, testing JSON objects, and validating a JSON payload

Writing Testable Scripts

To prepare your script that needs to be tested, it should always return JSON to the script that called it. This means that if the script fails, it should return an error JSON object. If it succeeds, it should return an object representing the data that was changed. See the example script called “Create a Project” in FileToTest. You will notice that it returns verbose errors on all failures, and returns a JSON object when successful.

Writing The Test Script

To prepare your test script, you need to do three things in karbon_tester:

  1. Create a JSON Object to pass the script using the layout “Edit Test Data”
  2. Create a script in the Folder “Project Testing” (Copy the existing scripts…you’ll get the idea!)
  3. Add the script you created to the script “Test – Project”

Do We Test Every Script?

There is no reason to test each & every script. We only write tests for those scripts that play a critical role in the solution. Once you are comfortable with testing, it will become clear what you should test. It’s up to you.

Benefits of FileMaker Testing

The benefits of creating test scripts are compelling. First, it provides any solution with a level of stability that is difficult to achieve in a timely fashion. If multiple developers are collaborating on the same solution, the test file enables everyone to run common tests on core business logic, and see if they have produced any unforeseen fatal errors.

Second, it provides a level of clarity for you, the developer. Once you begin writing tests, you will take on an alternate persona, where you are actively poking holes in your own code. This may seem like a small difference, but we believe you’ll be surprised once you try it. You become much more critical, which improves your focus & clarity.

Third, the readability of your code will improve. One thing that makes JSON difficult to handle is that there is not a repository for JSON objects within a FileMaker solution. When a script is designed to handle records in multiple tables, karbon_tester serves as a clear, contextual example of how to create & pass JSON objects to work within a solution.

Is it Worth It?

The first question many people seem to ask when introduced to testing is “is this worth it?” Our answer would be that it depends on the solution. If you have a complex system, multiple developers, and a need for stable solutions, it’s not just worth it, it should be the standard.

Download

To start, download our sample files here. Open “FileToTest”, and create a project. Review the script “Create a Project” to see how the file works. Then open the file “Karbon_Tester” and run the existing test. See how easy that was? Now you should create your own scripts to test creating a status.

What About Editing Data & Managing Test Data?

We will be releasing part 2 in this series in the future. We will walk through options for loading test data, & managing records that are used only for testing. The testing in this sample is intentionally simple to grasp and does not confront some of the nuanced issues involved in testing.

What about Karbon?

We know some have you have been waiting for us to release some of internal tools and frameworks that we group under something we call “Karbon”.  This is the piece piece of that puzzle.  More coming soon.

My presentation, "JavaScript is Eating the World" was released last week along with the rest of the Web Track presentations. Update: JavaScript People Please note. This talk was aimed at people who haven't done much Node or React. So there is some intro material you may not find useful.  The Javascr

My presentation, “JavaScript is Eating the World” was released last week along with the rest of the Web Track presentations.

Read more

We rolled out a new version of Barcode Creator over the weekend. We added support for another symbology bringing the total to 19, and we added one improvement to the QR Code generation. This upgrade is free for all owners of Barcode Creator. You can download it from your account at Geist Interactive

New Symbology

Added the “GS1 DataBar Expanded” symbology. This is the same as DataBar Expanded, but with strict GS1 validation. (DataBar Expanded behaves the same: it will still encode data as GS1 if the input follows GS1 formatting rules, but will also tolerate non-GS1 data, as before.)

Improvements

Improved QR Code compatibility with scanners that do not use the default configuration from the QR Code 2005 specification (including FileMaker Go).

Upgrading

It is always best to start over. Delete the old Barcode Creator module folder and copy and paste or import the new one into your file. Then reconnect your scripts.