To celebrate DevCon 2018, the newest release of the FileMaker platform, and all things JavaScript, Geist Interactive is pleased to begin a contest called GoCreate, where you get to go wild and show off your most unique use of GoDraw3.
Use all of the power of GoDraw3 to create a unique user experience to solve a particular use case. Read all about GoDraw3, but here are some things you might want to consider:
  • Any of the tools and functionality can be removed or customized.
  • The app is simply FileMaker. Use all of your knowledge and skills of FileMaker.
  • Tagged objects can be used in some awesome way.

Who can get involved:

This contest is open to anyone attending DevCon 2018 of any skill level. Since GoDraw3 is simply FileMaker, anyone can participate; no knowledge of JavaScript is needed.

Here are the details:

  • Use the fully-functional trial version and use that for your implementation.
    • Note: the trial version includes a watermark image. Ignore it.
  • Contest Date range: Now through August 9 at 8:00 a.m.
    • Feel free to work on it now!!! Get Started.
    • Or wait until DevCon.
  • Where: DevCon 2018. You must be a DevCon attendee to win.
  • Winner announcement at 3:30 p.m. on August 9.

Here’s what to do:

  • Download the trial version of GoDraw3 and create a unique implementation of it. Be creative. Create something that would work for any of your current work, or go wild and dream beyond your day job.
  • Email a link to your project to


  • You must use GoDraw3 in your implementation.
  • You can use any part of the FileMaker platform including FileMaker 16 or 17 to create your design.
  • You can design it for FileMaker Go or FileMaker Pro Advanced. You’ll let us know which device it is meant to be on.
  • Your work must not contain any real customer data.
  • You are limited to one entry per person.
  • Your work will only be considered if you’ve emailed a link to your project to


A team of independent FileMaker developers at DevCon will judge each entry, scoring your submission as they reflect on:

  • How clever of an implementation is presented.
  • How does the submission ‘feel’?

Granted, these are rather subjective, but we’ll do our best to make it fair.


You can get support and questions answered in the following ways:

We will be available to answer specific questions about GoDraw3, not about how you can implement it. We want to see what you can do! 🙂


GoCreate! Using FileMaker GoDraw for something awesome

We’re excited to see what you create with GoDraw3.

Terms and Conditions
  • You only officially enter the competition when you have emailed a link to your project to
  • All submissions become property of Geist Interactive and will be used in promotional materials. We will credit the author.
  • Submissions have to follow the rules as set out above.
  • All entries must be submitted by August 9 at 8:00 a.m.
  • Geist Interactive have the right to remove any entry at their sole discretion.
  • Objectionable or offensive content will be disqualified.
  • The competition will be judged by an independent panel of FileMaker Developers from the community. The top three will be selected based on creativity, unique implementation of GoDraw3.
  • The winners will be announced at DevCon at 3:30 p.m. at the Geist Interactive booth and by email.
  • The winners have 7 days to respond and claim the prize; if no response has been received after 7 days, you forfeit your prize.
  • Geist Interactive reserves the right to exchange any prize for a prize of similar value.
  • The judges will be selected from folks outside Geist Interactive. 

You know me. I enjoy working with JavaScript. I learned it from my context of a FileMaker developer, and I think everyone can and should consider using it in some aspect of their work. We all can adopt a FileMaker integration. This year I’m lucky to teach a training session at DevCon, where I’ll guide people through the basics and how to apply it to their work. While not every answer I give on the forums is about some JavaScript integration, I do promote it where applicable.

The time barrier

But I do realize that there are barriers to the language for us FileMaker people. I asked a question about this a couple of weeks ago. Most people responded with ‘time’. They simply don’t have time to learn the language. I think that is more of a perception than reality, but I acknowledge that idea. My training session will work to break down that barrier, by the way.

Because of this perceived barrier, I want to give folks a way to use JavaScript integrations without actually knowing JavaScript. How you ask? Well, this goal is accomplished by a cleverly-created FileMaker file: The DataTables config file. Let’s take at this barrier-smashing setup.

Introducing DataTables Config

The goal of this file was to give anyone the ability to implement the DataTables integration into their custom app. And the DataTables JavaScript library provides a heck of a lot of functionality for list views or lists of related records with no additional coding. You can set up a web viewer that shows related records with column sorting, go-to-related-records, column or row colors, filtering, etc.

DataTablesConfig.fmp12 is a  FileMaker file that simply generates the JavaScript needed for the integration after the developer adds or removes functionality. Here’s what it looks like.

I’ll say it again. This config file lets you set up the DataTables integration without messing with the JavaScript. After only ten minutes of setting it up, the above configuration produces this:

Gettin’ you hooked

This config file is meant to be a gateway drug into using JavaScript. Once you try it out and see how much functionality it adds to your custom app and how easy it is to set up, you’ll be interested in diving into the JS code. I guarantee that. You’ll want to look at the JS code (it really is just text) that makes this all happen. You’ll find it is easy to read (JavaScript is easy to read) and you’ll be inspired to mess around with it, to change something to see what happens. And in this case, no one gets killed by the curiosity. Mess it up, you can use the config file to revert back.

You’ll be hooked on JavaScript, and then you can continue to learn more about the language. We at Geist Interactive will guide you along.

Features of the DataTables config file

There’s too much to explain in detail here in a blog post, so be sure and check out the video that walks you through the app. But here are some highlights of its features.

  1. DataTables comes with a lot of default features and options. If you don’t want to customize your implementation, you can generate the default code quickly.
  2. You can add or remove features and options using the FileMaker data fields and UX provided here.
  3. There are detailed examples of how to format the text you wish to put in. For example, if you choose to have your default table sorted by column 3, you can choose the ‘order’ option and then pass to that option the following text: [2, “asc”] (this is a 0-based index). That’s easy enough to type, don’t you think?
  4. You can add additional extensions to your implementation, functionality that makes the integration more complex. Such as something that looks like a sub-summary report (grouped records) in little time.
  5. There’s plenty of help and descriptions of the features.
  6. You can (and should) map your fields to this config, and you can describe how each column should behave.
  7. You can add a callback function (Run a FileMaker script when you click on a row) and even assign a column to use in the search.
  8. You can set this file up to be a module, a separate file next to your custom apps and link to it. This action allows you to use the code stored here to display the data.
  9. Give some basic custom styling to the table.

There’s so much more that can be done, and we’ll explore Extensions, custom CSS, and calling FileMaker scripts in later posts and videos.

FileMaker Integration: Give it a try

I strongly encourage you to give it a try. Play with it, mess it up, do all sorts of stuff to it and figure it out. I promise it will not take hours and hours (maybe one or two). It won’t be a huge drain on your life.

Download the free tool. Watch the video. There are some fine points in this, and it is best shown in the demonstration.

Feel free to reach out at with questions if you wish. I can answer some questions, or we can set up an implementation package to do some custom development with this configuration in your custom app.

Let me know how it goes.





The FileMaker platform keeps getting better. The yearly release schedule gives us plenty to look forward to in new features, and the timeline gives us plenty of time to get to know what has been included. One of the new features is called “Default Fields”. We can now set up default fields to be created with each table in each file. There are plenty of articles out there already, and the knowledge-base article is out now. But I’ve seen some questions in the forums, sometimes the same ones. I did some research and put together the answers here. Let’s dive into FileMaker Default Fields.

Where are the Default Fields?

FileMaker 17 includes the default defaultFields.xml file in this location:

  • Mac: Applications/FileMaker Pro 17 Advanced/FileMaker
  • Win: <drive>:\Program Files\FileMaker\FileMaker Pro 17 Advanced\Extensions\English

This is just the place to get the defaultFields.xml file. You shouldn’t move it. Just copy it and paste it to the proper location:

  • Mac: /Users/Shared/FileMaker/Shared/
  • Win: <drive>:\ProgramData\FileMaker\Shared\

Once there, you can open this file in a text editor (I use Visual Studio Code) and edit away.

How do we change the FileMaker default fields?

The defaultFields.xml file provided (and found in the location and placed in the location described above) allows us to make changes to the default fields. Here are some thoughts about it:

  • Start by making only a few changes to a field or two. Edit, save and see what happens when you create a new table. Get a feel for how the XML is written.
  • There’s a tag in the xml, near the bottom in the <tagList> tag, that identifies one of the fields as the primary key. Make sure that stays there if you plan on using addons in FileMaker 17 or any later version.

  • There’s a tag in the xml that identifies each of these fields as utility fields. It is found in the <TagList> tag: “#_FMI_0”. The 0 identifies it as utility. Remove it if you wish, but understand the (small) consequence of doing so (see below).
  • As you go to adjust a field’s xml, you can get immediate feedback by creating a new table in a .fmp12 file. If there’s any issue with the xml of a field, such as a missing ” or misspelled tag, that field will not be created. So give it a test.
  • If you’d rather not use FileMaker default fields, simply add a blank defaultfields.xml file to that shared location. This action prevents FileMaker default fields from being created.

How will default fields effect my development?

Using the FileMaker default fields can enhance our development in a small, but crucial way: You’ll create a table and immediately begin adding data fields to your system since these utility fields were automatically generated. Additionally, the following points illustrate more benefits:

  • We can add other utility fields by adjusting the defaultFields.xml file.
  • We can set this defaultFields.xml file up once and be done.
  • Every table will have common utility fields which record the basic necessities: primary keys, creation & modification user & timestamp.
  • We’ll never have to copy/paste the utility fields from one table to another. One less thing to worry about. I’m sure folks have forgotten to add these at one time or another.
  • Since these are utility fields, they do not get added to the layout automatically (as do fields that are created by you during the creation of the table) .
  • Utility field-creation is consistent across an entire team.
  • A field is identified as the primary key field which is useful for add-ons.

How do I add a certain type of field?

Many folks have asked in the forums how to create a certain kind of field. An amazing tool, by Salvatore Colangelo at Goya, allows you to create the fields you want for each table by constructing the defaultFields.xml file. The FileMaker file actually writes the xml of the fields after we make choices (name, type, primary key, calculation, etc).

Of course you can simply duplicate the xml for a field in the document and adjust it as necessary. By hand. That’s useful too.

But consider a very key point:

Every field in the defaultFields.xml file will be created in every table of every file you work with in FileMaker 17. So if we add a “FirstName” field to our defaultFields.xml file, that field will get created even in the Invoices or Dashboard or Inventory table we create.

Only a few

It seems to me there’s only a few fields that could always be a part of the XML file. We here at Geist Interactive want some fields in every table. Some other developers have more, some less. Here’s ours.

  • primaryKey // the primary key of the table. UUIDNumber
  • ModificationUser //autoEnter field
  • ModificationTimeStamp // autoEnter field
  • CreationUser //autoEnter field
  • CreationTimeStamp //autoEnter field
  • z_One_c  // a calculation field that returns a 1. Useful for relationships.
  • ModCount // a calculation field that counts the number of times each record has been modified

Remember, these are utility fields, so they server a utility and are not data fields as it pertains to the custom app.

New Feature, New Thinking

The FileMaker Default Fields feature is new to FileMaker 17 and it provides some possible glimpse into the future. We, as developers, can create FileMaker fields using XML, either by hand or using a tool. That’s an interesting thought.

You’re already using them if you’re developing in FileMaker Pro 17 Advanced, so embrace them and make them your own and be happy. They are here to stay.




FileMaker DevCon 2018, held in Dallas, TX, is fast approaching, and as always, I’m excited for the conference. It certainly is a highlight of my year, where I get to go and see old friends, make new connections and friendships, and revel in all things FileMaker. The conference is held in a fancy hotel, but they could host it in a Hotel 6 for all I care. Sure a huge pool is wonderful to sit at, but the more time you’re at a resort feature, the more you’re missing FileMaker stuff.

An amazing pool and view doesn’t make DevCon great, does it? (DevCon 2016, Las Vegas)

For those that are attending FileMaker DevCon 2018 for the first time, it will be a FileMaker-life-changing experience. You’ll meet folks, learn a lot, and simply be inspired by the excitement about the platform. Even if the community sometimes can be intimidating for few folks and a bit of a drag with complaints or laments of ‘missing features’, the experience of being surrounded by FileMaker stuff in person is exciting.

This guide is meant to help you if you’re new to DevCon. My first one was only seven years ago. Each year I remember what made it so great and try to continue those practices and attitudes. Let’s review how to make this first time an inspiring and fruitful one.

Don’t Mess With the Conference

Every year, FileMaker, Inc. puts on a fantastic conference, filled with people, cool FileMaker tips & techniques, products, free advice, great food, and a great location. Last year around 1600 people attended, so the conference is huge. I know people look forward to it.

DevCon 2016, Las Vegas

Tim Cimbura of LuminFire has a great write up about some of the facts about the conference.

Take advantage of every part of the conference. Get your money’s worth. Here’s some of how you can do this very thing.

Organization tips

  • Get there early to meet folks before the conference starts. I usually hang out in the registration area where I know FileMaker folks will be.
  • Check in soon after you get there. Each year we get some cool FileMaker swag. I’ve got four FileMaker bags and one FileMaker towel from my conference experience. We’ll also get a license key for the current FileMaker Pro Advanced version and some other items, including a vital accessory from Geist Interactive, a diamond sponsor of FileMaker DevCon 2018.
  • Make a plan of the sessions you wish to attend. More info on this below.
  • Scope out the session rooms. Practice the route to the rooms so you don’t get lost or have to consult your phone every time you want to go to a session.
  • Attend the Keynote. FileMaker DevCon kicks off at the keynote officially, and here we get to see FileMaker, Inc. and the folks there on stage talking about the platform they’ve chosen to spend their career improving for us. FileMaker, Inc. product managers and engineers emerge from their cubicles to show us what they’re currently working on back at the wedge.

Socialization Tips

  • Find a friend or two. If you’re coming by yourself, it’s quite intimidating to be in a sea of 1600 devs and not know anyone. So say hi. Make a friend early. My first time at FileMaker DevCon, I actually met someone through the community. We shared a room to save costs and I followed him around. He introduced me to folks and gave me advice. It was the start of a great friendship.
  • Visit the vendors. The main exhibit hall will be filled with booths of different FileMaker shops out there. We’ll have a booth, and we have cool things planned for that space. Also in that space is the Visionary bar and the FileMaker Tech Support Central. The visionary bar is filled with folks in the community holding office hours. You can come to them with any specific FileMaker problem (there is no couch) and get some advice from the experts. The Tech Support Center contains FileMaker, Inc. Engineers and designers that can talk to you about specific issues you might have with your app or with FileMaker.
  • Come join others at the New Attendee Meetup This is a session devoted to any first-timers. FileMaker, Inc. staff will be there to talk about the week and get you started. The Women of FileMaker is hosting a DevCon buddy program. Take advantage of this time to get to know other new folks and buddies that have been there many years.

Don’t miss any part of the conference.

Don’t Mess with the Sessions

There’s too many sessions for you to attend all of them, so be deliberate about which ones you want to attend. Take some time now to study the schedule and jot down topics you want to be a part of in person. Though each session is recorded and eventually posted to FileMaker’s YouTube channel, decide which sessions you’d like to be in the room during the time. TheDevCon2Go Scheduler custom app will be released soon, and you can use that on your devices to mark your favorite sessions and to review the schedule in advance.

Attentive listening in a session.

If you’re a FileMaker beginner, attend some beginner sessions, but also attend some more-advanced ones. You might not fully understand everything presented, but the stretch in content will further inspire you. Also attend sessions on stuff you’ve never used or heard of: cURL, JSON, integrations, IoT, all the things that you might not see yourself using. These innovation sessions are the future of the platform, so be sure and get in on the ground floor.

If you are able, attend a training-day session. They are held on the Monday of the conference and are an additional cost, but these sessions (3.5 hours in length) are more hands-on and more exploratory than the hour-long sessions of the regular conference. There are always beginner, intermediate, advanced sessions. The topics range from basic FileMaker to reporting and user experience design. I’m teaching a session on JavaScript for FileMaker developers.

Don’t Mess with your Health

The conference is a week, but a lot happens in that week. Protect yourself and keep yourself healthy. Here’s some ways you can do that:

  • Bring sunscreen. It’s Texas.
  • Bring a water bottle. It’s Texas.
  • Bring warm clothes. It’s Texas, and we’re indoors. The AC will be blasting and cold. Of course when you step outside into the sunshine, you’ll bake in all the layers, but at least you’ll not freeze in the sessions.
  • Exercise. You’re doing a lot of sitting in the sessions, and we know that sitting is the new cancer. Get outside and walk (at like 5 am) or late at night (2 am). Hit the hotel gym or pool. Listen to your Apple Watch (we all have one, right?).
  • Rest / Get away. Above I’ve encouraged you to attend all you can, but you have to rest. So if you’re exhausted on Wednesday, take a moment to yourself. The hotel is huge, so find a quiet spot to just zone out (preferably not in a session) and recharge.

Don’t Mess with the Opportunities

FileMaker DevCon is the best place for a FileMaker developer to go. For the first timer, it is inspiring and overwhelming and excellent. There’s so much to take in, so many folks to meet. I encourage you to take advantage of every opportunity given at DevCon and be a part of this great community. Meet folks that you’ve talked with in the community forums. Learn a lot. Meet at least four new people. Visit vendors and booths. Learn what’s exciting about the platform.

Say hi to us at Geist Interactive.

We’ll be there at our booth demoing Editor and GoDraw and Quickbooks and other products, or walking around with our company t-shirts. Be sure and strike up a conversation about JSON or Native FileMaker or the FileMaker platform. We have a few things to say about those I’m sure.

Meet FileMaker, Inc. folks. They are some of the most friendly and passionate people about their platform I know. Four years ago now, I met the PM of the FileMaker Pro Advanced product. We’ve become good friends. We chat about FileMaker, about video games, about yard work.

Don’t Mess with FileMaker DevCon

Do everything you can to get the most you can out of FileMaker DevCon. You’ll be grateful that you got your (or your company’s) money worth. You’ll be inspired and energized and ready to push yourself to become better in the platform.

FileMaker 17 introduces a new script step: Perform Script by Name.  FileMaker Devs have been asking for this feature for a long time. It sounds like a useful idea, but we should probably try to understand how it works before we just adopt it willy-nilly, for all our script calling needs.  Let’s explore this idea together.

Perform Script by Name: The basics

Perform Script By Name is a script step that functions as it is named. We now have two options when using the Perform Script step: By Name  & From list.

If “From list” is chosen, then we go about choosing a script in the normal way. However, if “By name” is selected, we get to set the name of the script using the calculation dialog.

At the script’s runtime, this step checks to see if the script is in the list of scripts and runs that one. If it isn’t in the list, then we get the good ol’ message:

We can suppress the message with the Set Error Capture [on] step and capture the error (104 Script is missing) with the Get (LastError) function.

In a multi-file solution, we can use this same step to call a script in another file using the same table/field format: ExternalFileRefName::ScriptName.

Notice this step is using the external file reference name, not the actual file name. We need to use the name we gave to the file reference.

Pretty simple. There doesn’t seem to be much else to this. Set the name of the script or external file reference name and script in some manner, and this step will run that script.

Oh, by the way, this works for Perform Script on Server as well. As we set up a script to run there, we are presented with the same dialog.

Wait, what? Why is this useful?

Here in FileMaker Pro 17 Advanced, we have the option to set a script name and run that script, a step that belongs in the ‘by name’ group of steps: Set Field By Name, Go to Layout by Name, and this one. When I first saw it, it struck me as odd: why would I ever use this step that adds another source of indirection to my file and is fragile. Let’s consider its possible uses and the idea that this step is fragile to see if we can find some workarounds.

It is useful after all

The option to perform script by name is actually useful. It seems to get rid of complex If / Else if / End if logic steps that determine the script to run. Maybe in a custom app, there’s a script called “Edit” and this script is run from a student record and a teacher record. The first part of this Edit script would have to use the If logic to determine which edit script to run, something like

Quite a few script steps.

With this new option, we can reduce the steps:

This does seem useful. It would certainly reduce the number of steps needed to determine the script. In a recent project, I saw one navigation script that ran for the entire system. IT was literally 150 lines long with a bunch of Else If logic steps. It was tough to debug. So there’s that. This option is useful.

Notice in the example above, I’m setting the name of the script into a variable and then passing that variable into the Perform Script step. That seems useful and handy.

Since the name of the script is a calculation dialog, I have a plethora of ways to get the script. I can construct it like shown above. I could get it from some preference table, or I could pass in the script name via a parameter, to name a few.

This new option in Perform Script allows us to write some pretty complex logic in a simpler way. If reducing the number of lines of code is your goal, Perform Script By Name is a must-use.

“Fra-gee-lay. It must be Italian”

Any developer’s first thought about this script step is that it can be easily broken. If my script name today is “ThatScript” and for some reason (legit or not) I decide to change it to “That Script”, then my perform script by name step is broken. That is certainly true.

Another factor to consider is that Perform Script By Name is another source of indirection, one that our Realtime Developer Intelligence tool FMPerception can find and point out, but this is an indirect source. Every time I use Perform Script by Name [“ThatScript”] I reduce the number of times FMPerception or database analysis tools can identify in the DDR where and when that script is used. That’s not bad. It is just something to consider.

But just because something is fragile or introduces indirection, there’s no reason to avoid this script step option. There are possible workarounds to the fragility issue. Let’s take a look at some of those.


Don’t change names

The first ‘workaround’ I can think of is: don’t change your script names. It seems obvious, but also almost unthinkable. FIleMaker is a rapid-application development tool. We can create a custom app quickly and easily, and that includes changing things on the fly. If our fieldName or script or layout’s original name is now unsatisfactory to us, it is easy to change. FileMaker after all actually looks at the ID of fields, layouts, scripts when calling or going to or setting. We’ve had it easy: change names as much as we want. I’d argue that this is a sign of not-fully-thought out planning, but I make no judgements. It happens. But I’d encourage us to change names of things as little as possible.


Second, if we do start using a script in the ‘by name’ option of Perform Script, we need to very clearly document that. In the above pictures, my script “ThatScript” is being used in the ‘by name’ option. So I should go over to “ThatScript” and document at the top “###### USED IN PERFORM SCRIPT BY NAME. DO NOT CHANGE THE NAME ######” or something along those lines to inform everyone, including your future self, to tread carefully with this script. Or put these called scripts in a “BY NAME” folder. Something to alert folks to its special case.

Generate script names

Third, we can generate the name of the scripts that will be used in the following parent script. 

At the top of my Edit_Record script, I have a code block that gathers the names of the scripts that could be used in this parent script. I first set a global variable to 1. Then I go into each of the scripts that could be used.

Inside each script, at the top, I immediately exit with the script name.

and then collect that name into a JSON object, in my case, in $scripts.

This works. It adds complexity to your parent script, but it does ensure that I get the correct script name each time.

Other possibilities

There’s more ways to ensure that you have the correct script names every time. There’s a good function I just discovered: ScriptNames(). It returns a list of the scripts in a file. That could be useful somehow. Maybe you could gather all the scripts into a global and then check against this list every time using Filter().

Don’t be afraid

This new option is useful and valuable in the right circumstances. I’d say we shouldn’t be afraid of it or avoid it. Use it where appropriate. But don’t go overboard. Don’t use it like we all started using ExecuteSQL() when it came out (that is, everywhere).

Be deliberate in its use. Document the heck out of scripts that are used in this “by name” manner, and be careful about refactoring script names for no good reason.

I look forward to using this to simplify complex logic. Give it a try, and let us know how you use the new Perform Script by Name step.



Introducing Editor.

Editor is THE rich-text editing tool for FileMaker, for FileMaker Go, and FileMaker on the desktop (it does not work in FileMaker WebDirect). It is familiar for users and flexible for developers. Editor provides a full-suite of text-formatting tools for writing projects such as notes and blog posts. The formatting is saved, and can be retrieved for further editing. Editor is the best way to provide formatted text for FileMaker.

Familiar for the User

Editor provides many of the formatting options we use every day in online editing tools.

Any user can

  • Change the style of text: h1, h2, h3, normal, and code (among others).
  • Apply bold, italics, strike-thru, underline formatting.
  • Align text in standard ways
  • Add ordered or unordered lists
  • Indent or outdent text
  • Insert text or images
  • Change the font or background color.

Additionally, FileMaker scripts can be used to add pre-defined text and images.

Flexibility for the Developer

Editor is all Native FileMaker

Even though the editor and the text is a JavaScript application running in a web viewer, the developer has complete control of the implementation and customization of the app. Here are some reasons why.

  • The web viewer app is self-contained in a separate file, making it easy to integrate into an existing custom app.
  • The design of the layout and toolbar buttons (outside the web viewer) is all done in FileMaker. You can completely change how it looks just using FileMaker layout mode.
  • The buttons run FileMaker scripts.
  • The editor toolbar and theme can be controlled via scripts. If you want to remove the “h1” formatting option, remove that from the scripting.

See the possible customization options available.

The Best FileMaker Rich-Text Experience

Editor is the best way to format text in FileMaker We’re excited about the potential. We have lots of thoughts about how it can be used, and we will be sharing ideas.

Learn all about Editor

Download it for free to try it out. The demo comes fully functional, though it does have a 1000 character limit. So give it a spin and see how easy it is to format (and save) text in FileMaker.


We at Geist Interactive are excited about the newest (yearly) release of the FileMaker platform. It is a great step forward and provides a lot of game-changing features yet again. We get to throw out “hacky” ways of doing such things as master-detail and instead use the new features of native FileMaker.

Wednesday, June 20, we will examine the platform’s latest release. We will examine the features, and review the use and usefulness of each feature. It will be a discussion, so come prepared to talk about your favorite part of the newest release of FileMaker 17.


Where: WeWork Aventine (not WeWork B street) || 

When: June 20, 2018 || 3-6pm

Why: There will be refreshments, and we get to talk FileMaker 17.


Join us. Let us know through and we’ll make a space for yah!


FileMaker Pro Advanced gives us developers to create our custom function, our own calculation that returns a result. These are FileMaker Custom Functions. Using custom functions is a boss-level technique, and we all now get to use them and share them. With great power comes great thinking: you as a developer get to decide when/how to use them. But first, let’s take a look at how to work with custom functions.

FileMaker custom functions

Custom functions are lines of code that we write that returns a simple or complex result. They are found in the “File / Manage Custom Functions” menu.

FIleMaker Custom Function dialog

Here is where you create a custom function

Custom Functions have a few characteristics to them:

  • They require a name.
  • They can accept parameters, but don’t have to.
  • Some sort of calculation is required.
  • They are file specific
  • At this time, the custom function dialog is not type-ahead enabled, as is a regular calc dialog.
  • They can return one result or a recursive result.

Let’s look at each of these.

Require a name

Once a name is given, the custom function is available in both the functions list (under custom functions) or as part of the typeahead. Some folks clearly identify a custom function in its name with some prefix. I tend to use “_” at the beginning: “_CF_BeginningOfWeek”, (a function that returns the date of the first day of a week) but the structure can be anything, even containing spaces between words.

Accept parameters

Parameters are bits of information we pass into the custom function and is used in the calculation. These parameters are in the ( ) that appears after the name.. For example in the “_CF_BeginningOfWeek ( anyDate)” custom function, I am passing in a date. I’ve named it “anyDate” but that’s what it could be. I could work with any of these:

_CF_BeginningOfWeek ( Get ( CurrentDate ) )
_CF_BeginningOfWeek ( Date ( 3 ; 19 ;2018 ) )
_CF_BeginningOfWeek ( “5/8/2018” )

What’s in the parentheses gets passed into the custom function and is used throughout. For example, in this custom function, Date ( 3; 19; 2018) is passed into the calculation, and this value is assigned to the variable “anyDate”, the one I put in the CF set up.

Let ([
 _dow = DayOfWeek ( anyDate ); //anyDate = 3/19/2018
 _first = _dow - (_dow - 1);
 _end = ""
GetAsDate (_date - _first)

A CF can contain any number of parameters, including zero. Many folks create custom functions that turn the numerical returned value from a FileMaker function into something readable. The FileMaker function Get ( Device ) returns 1 if the user is on the mac. Would you remember 1 being the Mac (especially is your device of choice is a machine with the Windows OS)?

So folks will take this function into a custom function and call the custom function instead.

One other note about parameters, you can use any number of parameters, and each one must contain something passed to it. Look at this custom function called _IsOverlap. Its purpose is to determine if two date ranges overlap.

As I built this for a project, I realized that sometimes there is no end date for one of the ranges. I still need this to work, so I have to pass something into the custom function for the end dates. So inside the custom function, I’m checking to see if the EndDate parameters are empty. If so, I put a placeholder date in there.

The calculation

The whole point of a custom function is to do some calculation, so do something in this section. You can use any combination of existing FileMaker custom functions, from-scratch calculations or even other custom functions (provided those exist already).

The calculation can be simple or complex. It all depends on your needs, as we’ll discuss in a bit.

Other characteristics

Custom functions are file specific. Each file has zero custom functions at first creation. But it is a simple matter of copying a set of custom functions from one to another file. Simply select the ones to copy in Manage Custom Functions in File A and paste them in the same dialog in File B.
The custom function calculation dialog does not have the type-ahead feature we’ve not gotten used to in other areas. Some folks complain. I don’t. I deal with it and move on. You can select FileMaker functions from the dialog, but it is simpler to type them out.

And finally, custom functions can be used to be recursive, to call itself until a condition is met, and then return the result. We will address these in a later post.

Well-used custom functions

FileMaker custom functions have their uses, and you can make the decision for yourselves. Here are a few good thoughts on it by others. Beyond that, it’s a simple decision to make when considering a CF based on these ideas.

One calc used many times

There is a calculation that does exist in FileMaker that will need to be used throughout the whole custom app. If many places in your app require the date of the first day of any week, then that seems a likely candidate for a CF. This has an added benefit that if the calculation needs to be changed for some reason, (returning the Sunday date instead of Monday date), there’s one place to update all the results. That’s useful.

Human-readable result

You want a result that makes sense to humans: _CF_GetDevice() will return “Mac” instead of 1. Making it readable means you don’t have to even think. Here’s another example of a set of custom functions using the Get(Device) FileMaker function

Each of these returns 1 or 0, true or false for a given device.

These can be used in a series of logic script steps. For example:

One more thing

In the history of the custom functions, many people have discussed the pros and cons about them. Some of those cons have gone away now that we all have access to the feature, but it is worth noting there still are a few. We’ll look at those in a later post.

Resources for Custom Functions:

There are tons of FileMaker custom functions out there for different purposes. Developers come up with CF’s that fit a specific need and then make it available. Here are just a few resources.

FileMaker Custom functions are a part of the full toolbox we all now have at our fingertips. Knowing how they work and when/why you would use them is important. Explore them and see how they fit into your development work.

Today’s post comes from my colleague Barbara Cooney. Here she reports on the PauseOnError 2018.

It was nine years ago that I attended the very first PauseOnError (PoE) in NY at the Ace Hotel. We crammed into each other’s hotel rooms, some sitting on the floor. There we presented and discussed new techniques sharing the challenges and accomplishments we had encountered in our effort to improve our FileMaker skill set. I was an independent developer, and somewhat isolated. So I was encouraged to meet the people behind the screen names with whom I’d exchanged countless discussions on the forums. It recharged me.

PauseOnError Hits the Big Leagues

Two weeks ago, I attended a much more structured and larger PauseOnError, sponsored by the WomenOfFileMaker.  The event was held in the welcoming and creative city of New Orleans. The hotel we stayed at was lush and extravagant and a perfect setting for an intimate gathering of FileMaker pros.

The hotel for PauseOnError was extravagant. Photo Credit:

The hotel for PauseOnError was extravagant. Photo Credit:

The Theme

PauseOnError was organized by the Women Of FileMaker, and the theme they choose was “Stand Tall”.

Martha Zink, Susan Dean Fennema, and Lisette Wilson kicked things off.

Martha Zink, Susan Dean Fennema, and Lisette Wilson kicked things off.

We stood tall by telling our stories from our name tags to an entire session called “Tell Your Story”. Many of the sessions included this theme in their discussion. It was inspiring to hear of others’ journey too and through FileMaker.

Our nametags gave a little insight into who we are.

A Wide-Range of Presentations

The sessions encompassed many topics. The range spanned growing your FileMaker business to leveraging its position as a platform that can integrate easily with other systems. Since joining Geist Interactive, I’ve already been involved in several API integrations. Here I choose to both validate and expand my knowledge in those integrations sessions.

Lots of API topics

In one of the first sessions, Jeremy Upton’s curiosity led him to explore the developer tools available from Amazon to integrate Alexa. Imagine being able to ask your FileMaker database “what were last month’s sales?” And have Alexa answer back!

Sol Rodriguez demonstrated the use of RestFM with Google’s JavaScript Framework, Angular, to quickly provide web-based access to a FileMaker system. His enthusiasm for how approachable this world is for FileMaker developers was contagious. I plan to sign up for the Udemy course he highly recommended.

Chris Irvine introduced us to an alternative to REST, GraphQL, created by FaceBook. This language lets the user limit the data received back from an API call and in doing so, improve performance when latency is a concern.

Overall, what struck me about each of these sessions is each developer used tenacity and trial & error to push through that initial learning curve hump. The message is clear:

  • You can do this too the tools are out there.
  • It’s achievable.
  • You’ve got a community of developers that will support you.

And Other Topics

Taking a break from API approaches, I attended Anton Anderson’s session. It offered instruction on the use of graphical tools such as FlowCharts and ERDs to communicate complex workflows and relationships, so that you and your client share the same understanding.

Mike Beargie demonstrated how to build modular files which allow you to reuse functionality across several solutions, using JSON to pass parameters and results.

Women of FileMaker

The last session that I attended was dedicated to Women in FileMaker. Here, Martha Zink interviewed several community leaders and asked them to share their challenges, achievements and how their attitudes have changed during their careers.


Photo Credit: Credit:

I was struck with the similarities to my own experiences in my 25 years as a women developer in a male-dominated industry. I gained a sense of confidence listening to how they too overcame the need for perfection and crisis of confidence with which many women are burdened. The top developers, as I saw first hand in the sessions I attended, and witness at Geist, learn by trying, making mistakes, revising and ultimately accomplishing their goal. No one gets it right the first time and expecting to do so is self-defeating. As Dave Ramsey of FMPerception fame explained, “errors allow me to see how it can fail, and that is important info to have too.”

A Fulfilling Pause

Poetically, I ended PauseOnError by running into Ernest Koe, one of the founders of the first POE, in the elevator. He was curious of my reaction to this experience of Pause. I assured him that the camaraderie was still there and the excitement of interacting with community leaders hadn’t diminished. I’m more than ever optimistic of FileMaker’s future and my ability to help my clients accomplish their goals. I’m looking forward to DevCon.

I think it is time we stopped getting too worked up about product version numbers. FileMaker is not a Product. It is a Platform. Platforms are different. They don’t really have a product release every 2 to 4 years. They have regular releases of whatever is ready to go.  That’s why I don’t care much about the number 17.  It has great new features and capabilities that once again improve how we approach how we build apps, just like last years big game changer. Let’s take a closer look, shall we?

Missing the Point

I see a lot of bitching about how FileMaker 17 should be FileMaker 16.5 because it doesn’t have enough new features for end users to get a new version number. Frankly, those forum posts are missing the point. First, this release does have several game-changing features and capabilities.  Second, as I just said FileMaker is a platform, not a product. If you know the difference between the two, all this kvetching over a given release and its number seem pointless. We get a new version every year. It always includes new great stuff. The next batch of new stuff is about a year away.

FileMaker 17 Features I won’t be Talking About

Most of them :-). We’ll have other blog posts that will go into more detail on each of the new features and how they work.  In this post I want to focus on just a couple that I think have major implications for the platform and not necessarily because of what they do specifically in your apps, but because of how they might affect how we approach building high-value FileMaker apps for our organizations and customers.

The End Of a Two-Class System

FileMaker 17 Pro Advanced is now the only Desktop client. There is no more FileMaker Pro. That means that everyone has access to the advanced tools:  custom functions, the DDR, custom menus etc. Everyone can copy and paste the code. Everyone can take advantage of RealTime Developer Intelligence Tools like FMPerception and Analysis Tools like Base Elements and Inspector Pro.

There are no more “haves” and “have-nots”. Just “haves”

This means that product developers can no drop the ridiculous work-a-rounds to handle the fact that most of their customers wouldn’t be able to copy custom functions into their files.

Modular FileMaker 2.0 Guidelines when they are released at FileMaker DevCon 2018 will drop the guideline about not using Custom Functions completely. I was famous for advising against Custom Functions in the past because it decreased the likely hood that code could be re-used by other people, who didn’t have advanced. Since it was focused on sharing code, Modular FileMaker 1.0 Guidelines suggested not using them. While I have moderated that position over the years somewhat, but now we can embrace them fully.

Since everyone is on an equal playing field now it will be easier to teach people to share code and build products that everyone can use.

Less UI Hacks, More Business Logic.

I spent years developing workarounds to UI limitations in FileMaker. Back when we got one release every 30 months and they NEVER included new UI widgets and patterns, this might have made sense, but FileMaker 17’s Master-Detail feature has convinced me that is no longer a good use of time.

Over the last couple of years, FileMaker has added major new UI features that change the way you might develop your interface. We have Popovers, button bars, Top Nav, Card Windows, just to name a few. With this release, we get Master-Detail. It no longer makes sense to waste cycles building up massive leaky abstractions like my old version of MasterDetail.

Instead, I think we should focus on the parts of our system that aren’t going to change as much, the data layer and the logic layer. Maybe design systems so you could rebuild the UI at any time, without having to rebuild the data layer and the business logic.

Data Migrations

The fmDatamigration tool is a game changer. Using our soon to be released Otto product, we have fully automated multi-file GB data migrations going from Development servers to Production servers in just minutes. That is not a typo. GB data migrations from server to server in just minutes! The implications of this are massive and wide reaching.

You may still choose to separate your solution into multiple files, there are many reasons to do so. But avoiding data imports no longer needs to be the reason to do it. Becuase you are free from worrying about data imports, you can find different ways of separating that make more sense for your scenario. You might want to make some features more of a self-contained module that can be maintained separately. Or you may shover everything back into one file. It’s up to you.

Live development on production servers has always been frowned upon.  But it was almost a necessity because some systems could take hours or even days to go through the data migration.  That excuse is now gone.  If you run a busy complex FileMaker solution, you should be doing development on a development server, and doing regular automatic migrations.

The Data API is Out of Beta

The Data API is now out of beta and includes a tiered pricing model that fits nicely into the new simpler overall licensing model.  Finally, we have a pricing model that makes sense.

Developers can feel confident about building on top of the new Data API, because it is official, and generates revenue for FileMaker.  I know some folks wanted it to be free so they could get around FileMaker License costs, but really that is a very shorted sighted view.  If you rely on the FileMaker platform you should want the vendor (FMI) to thrive.

Continuous Improvement

This year’s release ( notice how I didn’t say “17” ) includes a number of compelling improvements both to the end user experience and the developer experience. It is another step in a continuous process of improvement. Each year it gets better and better, and we would do well to work that fact into our plans.