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 Meetup.com 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: https://twitter.com/LauraJBetz

The hotel for PauseOnError was extravagant. Photo Credit: https://twitter.com/LauraJBetz

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: https://twitter.com/LauraJBetz

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.

Every custom app we build is a complex DNA strand of tables, fields, layout object and scripts, security privilege sets, conditional formatting, data-formatting options, relationships, calculations, indirection sources, and other attributes. The web these pieces creates starts simple in the first stages of development and we may even be able to keep it all in our heads. But as the custom app grows in functionality, data-storage, user-interfaces, it is easy to lose track of some part of it. I might have created a field called “zz_AccountName_g” and used it throughout, but months later, I cannot remember where I used it or even if I ever used it in a script or on a layout or in an privilege set. The FileMaker Database Design Report helps us to find that which we forgot.

FileMaker Database Design Report (DDR)

The FileMaker Database Design Report is meant to expose the DNA of a custom app, clearly identifying the locations and uses of fields, calculations, layouts, themes & styles, scripts, and other pieces. After running a DDR and processing it in some way, I can find the exact places the field “zz_AccountName_g” are used (if any). This exposure is essential for a developer’s sanity, efficiency in tracking down issues, and lean & well-organized custom apps.

Possible Uses

The DDR gives us the ability to find any part of our custom app. People use the DDR to do any of the following:

  • Find out where the field “zz_AccountName_g” is used throughout the system: what layouts it is on, what scripts use it, and any calculations (field definitions, conditional formatting, hide-conditions, etc.) that rely on the value.
  • Discover unreferenced fields or scripts/layouts that aren’t called from anywhere.
  • Find errors. This includes commented-out script steps or calculations, etc.
  • Read a script outside of the script workspace
  • Find indirection sources
  • Review the themes used and local styles.
  • Check the accounts that use the “EditOnly” privilege set.

This list is very incomplete. So remember this: you can find any part of your custom app using the DDR.

Start at the beginning.

FileMaker Pro Advanced users have access to an additional menu: Tools

Here is where the Database Design Report is found.

The dialog that comes up is fairly simple.

In this dialog box you have:

  • Available Files: These are all the files you have currently open. Those files checked will combine into one DDR, so make sure there’s no extraneous ones lurking about. With a multi-file solution, however, you’ll want all those included in the DDR. Just make sure each file is open before running the DDR.
  • Include Fields from Tables: The top-right box allows us to deselect some tables we don’t want included in the DDR.  This might come in handy, but I’ve rarely done this. Of course it depends on the size of the file; if your goal is to see only where one field in one table is used, you can only select that table.
  • Include in Report: The middle box lists what to include in the report. Again, it seems worth it to leave all these checked except for rare circumstances.
  • Report Format: This choice describes the kind of output you want. There are two: HTML and XML. Both are valid and useful, but the XML is MUCH more useful than the HTML format.
  • File Handling: I rarely immediately open the file, especially if I’m using the XML format.

When I click on Create, FileMaker produces a Summary file and a file for each FileMaker file included in the report. Any use of these files (opening, importing) starts at the Summary file.

The HTML format

The HTML format looks like this.

It is an HTML page that includes a long barely-formatted table of all the components of the DDR. Each column contains a helpful link to take you to its details. When I click on “31” under the Tables header, I am taken to this:

Now I can navigate anywhere in the report, to fields, to scripts that use a certain field, to all the relationships in which a certain table is used. Anything.

Run an HTML DDR on one of your files and click around in there. Go ahead. I’ll wait.

The HTML report can be useful, but navigating through the HTML document can get unwieldy. I personally never use this report. Instead, I create my DDRs in the XML format.


We FileMaker developers are interested in completing a task in the fewest clicks, and that includes finding a field in the complex DDR. Database analysis tools such as Base Elements and Inspector, and Realtime Developer Intelligence tools such as FMPerception allow us to find a field or calculation or conditional formatting logic extremely quickly. And these tools use the XML DDR. So this is the format I recommend (and most all developers use).
After creating the DDR in this format, you can use the tools mentioned above and either import the Summary.xml  (Base Elements & Inspector) or just open the Summary.xml in FMPerception. Here’s what a DDR looks like in FMPerception.

FMPerception and the other tools mentioned provide much easier access to every last byte of your custom app. They provide searches, drill-downs, reporting functions, and other organization tools.

Organization & Frequency

FileMaker developers lean heavily on the DDR and the tools that help them read the DDRs. These folks run DDRs on a regular basis

Before Development begins:

If a developer takes over the development, she will run a DDR and bring into a tool before any work begins. She’ll review the DDR to see its current state, looking for errors, unused elements, and overall structure. The reporting tools help her see the basic current state.

During Development

I’ve known developers to run a DDR on a regular basis: every hour, every week, every day, at the start of their work day, or before a work sprint. This DDR reflects the current state and shows the changes made recently. Tech leads use the daily DDR to keep an eye on errors or large structure changes. Developers use it to look up where a certain field is used.

After Development

After the custom app has gone through a development cycle and then has been released, a DDR is run to capture its final state. Again, post-work analysis can be done with the DDR. This DDR becomes documentation on the current release. This has an advantage too of helping us to identify and changes made by the client after they started working with the file.

Organization & Frequency

Running DDRs and importing them into the analysis or intelligence tools will cause you think about organization of the files since each DDR overwrites the previous one if you let it. So think about how you will organize these files.
I typically set up a “DDR” folder in my overall project folder. Inside this DDR folder is a folder for each day the DDR is run.

This method keeps all the DDRs organized proper. You can, at anytime, find a previous DDR, open it up again and compare it to the current one.

Rely on the FileMaker Database Design Report

The FileMaker Database Design Report is an essential tool for all FileMaker Developers, and all FileMaker developers can use this tool to better understand their custom apps. As you start using it, you’ll find that you can’t live without it.

You, Ms. / Mr. FileMaker developer can be a JavaScript developer as well. You can learn JavaScript and use it in your daily work.

FileMaker folks are suited for JavaScript. Though we may have stumbled into the FileMaker platform, we have enough knowledge and conceptual understanding to program also in JavaScript. There are many reasons why we can learn and why we should learn JavaScript. Let’s examine them.

Can Learn

A simple & powerful language

JavaScript was designed to be a beginner’s language. Like the Dick & Jane books or Sesame Street, JS’s structure and language is simple. It uses normal words and and a straightforward syntax. I bet you could figure out what this JS function does:

function sum (){
var a = 3, b = 5;
return a + b;

(answer: this is a function called “sum” that assigns values to two variables and then returns the sum).

This simple language is appealing. That’s not to say the language is impotent in any way. It is incredibly powerful.  Complex powerful applications that are used by billions of people around the world, like QuickBooks Online, and Facebook are built with JavaScript.

FileMaker knowledge

Our FileMaker knowledge can help us to learn JavaScript faster. We already have an understanding of such things as variables, variable scope, functions ( scripts and FM functions), and parameters. We can leverage what we know about FileMaker to help us learn JavaScript better.

The VAST community

On the recent StackOverflow survey, 62% of respondents said JS was their favorite language. People devote their career to working in JavaScript, so there’s a plethora of resources out there from which to learn and ask questions.

I learned it

Though I’m still plugging away, I feel pretty confident in my JavaScript knowledge. I played around with the language a lot and built countless FileMaker and html filles and watch hundreds of hours of video, but I learned it. You can too.

There are many reasons we can learn JavaScript. Let’s take a look at why we should learn the language.

Should Learn

Native FileMaker

We should learn JavaScript because it is a native part of FileMaker. It is supported on every part of the platform: FileMaker Pro and FileMaker Go runs JS in a web viewer, and FileMaker Server 16 includes node.js ( a JavaScript framework) in the install. Even WebDirect can run JavaScript in a limited way.

Since it is part of the platform, it behooves us to spend time with it and learn it. We can use JS to solve some vexing UI and scripting problems we occasionally encounter in normal FileMaker development. If your client wants a portal to have columns that sort in whatever combination she wants, a JavaScript library can solve this problem in much less time than it takes to develop it using FileMaker buttons and scripts.

If we have our way, FileMaker functions one day will call JavaScript functions. Right now we can do that with some small workaround (and will show that very soon). GoDraw3 uses this FileMaker-calling-JS-functions idea (check it out and download the unlocked trial version).

‘Tis the future

JavaScript will be around a long time:

  • JavaScript ranks number 1 in a survey of favorite languages or languages in use.
  • JavaScript is a cross-platform language.
  • The JS community invests tons of time in creating libraries
  • JS runs both on the client (in the browser) and server-side (using node.js).

If you do not learn it, your competitor will

Some day, some client will come to you with a use case to solve using their FileMaker custom app. Without the multi-tool capabilities of JS in your belt, the problem cannot be solved easily, and your client will find someone that can solve it.


I know you’re not looking, but knowing JS can open up other job possibilities. JS developers are few, and the jobs are abundant. It’s a developer’s market.

So what’s your excuse?

Answer: there is none. It is important for FileMaker developers to see beyond just scripts and layout objects and view what’s possible and the tools that make those possible. So learn it.

Okay, I thought of an excuse: timing / familiarity. Folks think they don’t have the time to learn something that looks scary. Learning FileMaker is a full-time job, they say. These folks do not recognize their brains are primed for this language. It’s scary to jump into something new.

Join me at DevCon & Learn JavaScript

At FileMaker DevCon 2018, I will do my best to help folks learn JavaScript concepts and some techniques, taking away the scary and unfamiliar nature of it. We will spend a half-day training session learning the syntax and JS concepts, and will spend lots of time coding. We’ll start with FileMaker and use our knowledge of that platform to learn JavaScript. My training session is on Monday, just before the full conference starts.

Learning objectives

We have specific learning objectives. You’ll walk away with a lot of knowledge:

By the end of the session, FMDWBAT*:

  • Write JavaScript apps using the FileMaker web viewer and a text field
  • Pass FileMaker data to a JavaScript function
  • Retrieve the result of a JavaScript function to FileMaker
  • Customize an integration of popular JavaScript libraries
  • Use FileMaker scripts to call JavaScript functions (passing data to and retrieving data from the JS function).

*FMDWBT = “FileMaker Developers will be able to” –a derivation of a phrase I wrote on my classroom chalkboard/ whiteboard / smartboard everyday that proceeded that day’s objectives.

Complete documentation

Because I’m a teacher, you will be given lots of materials with which to participate during the session and continue your study afterwards. Here’s what will be available during and after the training:

  • The similarities between FileMaker and JavaScript
  • JavaScript use cases of varying levels
  • A playground in which to try out our JS code.
  • Videos of yours truly demonstrating a JS app for your repeated viewing at your own pace.
  • Great differentiated help.
  • Extensions: tasks and learning materials continuing through the week. Who needs the pool when you can continue to solidly your knowledge of JS.

Welcome anyone of any level

Join me and learn JavaScript as painlessly as possible no matter where you’re at in your FileMaker development path.

I’m a teacher at heart, so I’m there to guide and redirect and support anyone. We will work together to bring JavaScript more into the community so that we can talk about it from the FileMaker perspective just as often in the community as we talk about SSL or ExecuteSQL.

Feel free to shoot me any questions about the training. I’m happy to answer them: jeremy@geistinteractive.com.

See you in just three months!



GoDraw3 is a FileMaker drawing tool. Since it is FileMaker (100% native) and since you are a FileMaker developer, you can take this tool and do anything you want with it.

Use it as it is

When you first open the trial version, you’re given a complete set of familiar drawing tools with which to draw on an image or create an image from scratch. A user can:

  • Place text on an image
  • Draw with a brush or a line
  • Change the color/size/stroke/opacity of an object
  • Add an image
  • Tag data to an object
  • Copy/paste an object
  • Delete / undo / redo actions
  • Group objects
  • Change the size of the drawing canvas
  • Select/rotate/scale objects
  • Zoom in and out

And much more. There are so many possibilities for the user to use this for FileMaker drawing.

That’s great.

What FileMaker developers do

But FileMaker developers (you and me) are interested in much more than drawing. We’re interested in hacking at any tool to make it work perfectly for our users and for the custom app. Well guess what, you Ms. FileMaker developer, can do that to GoDraw3. You can hack away at this tool until it barely resembles the example editor. Please. We want you to hack at it. We want you to make it your own, and we’ve set it up for that very purpose.

How is hacking this possible? Because GoDraw3 is pure FileMaker. There’s nothing else you need to worry about. Since you know FileMaker, you can do whatever you want with this. Here’s a list of possibilities (woefully incomplete):

  • Add tool tips to the buttons
  • Remove tools that your users don’t want
  • Rearrange the tools
  • Change the background color
  • Add a button that only draws a purple circle with 50% transparency and with a yellow stroke
  • Change the default text to be 100 pt using Arial
  • Tag data to an object, and save that data to FileMaker
  • Include Snippets (JSON objects) & Favorites (.png or .jpg files) for reuse
  • Add a button that places a red arrow onto the canvas.
  • Make different tools available for different users
  • Adjust the size of the canvas
  • Remove the color palette
  • Disable the scaling or rotating of an object
  • Create a visual data-entry only system

And much more.

My hack

Here’s my hack.

My Method

This really looks a lot different than the example file. Here’s what I did:

  • Removed most of the tools
  • Included only buttons that draw specific colored circles.
  • Cleared the document size (I overrode the default document size) so this could go on forever, and as the picture grows, so too does the size.
  • Added the “Circle” script to each button and adjusted the “Circle” script to collect the fill color from the parameter on each button. No longer does it set an empty $toolOptions variable (as the example does) but instead the script gets the script parameter as the options. The Red circle has this in the parameter:

Hack away

GoDraw3 is a FileMaker’s dream tool. It is perfectly fine as it is for drawing, but FileMaker hackers will take great pleasure in hacking the heck out of it.

Go ahead. Download it. Hack it. Do what you want with GoDraw3.

GoDraw3 contains the word “draw” in it, and it certainly is a drawing tool. But it is not just a drawing tool. It can be used as a FileMaker visual data-entry system.

At the Doc

Check out this example called “Patients.fmp12” which illustrates a possible use in a doctor’s office. A patient comes in and describes pain points on his body. The doctor uses this app to place icons on a human body diagram to where the patient tells her. She can actually use circles and mark up the diagram. That’s cool, but what’s even cooler is that each of these icons is tagged with data: the body part and the current state of the body part.

Marking up a human body diagram and tagging the objects

Marking up a human body diagram and tagging the objects

This poor patient gets to identify the broken parts of his body, and the doctor quickly and easily marks the diagram with red circles. Upon save, the data attached to each circle creates a record and is saved.

The data from the objects gets saved to a child table.

The data from the objects gets saved to a child table.

Further, when the patient returns and reports of progress, say his left shoulder is fixed, The doctor can update the data for the paint point mark.

Updating an object’s data in the image updates the data in the table.

 Using our FileMaker skills

The script that does this is fairly simple. I used the “Find All Tags”  that came with the exampleas a subscript with a few modifications. This parent script then does the actual parsing of the JSON and either creates a new record or edits the existing body part record.

Example script.

Example script.


Drawing as data entry

This is just one example. But think, for a moment of the possibilities. Any developer could easily create a FileMaker visual data-entry system that is primarily visual for any number of projects. Here’s a small list (Thanks to Kirk Rheinlander for some of these.):

  • Equipment locations in hospitals (one record per floor) containing dates of service, warranty information, point of contact.
  • Seating charts for a wedding or a classroom. Guests or students are in related records, and each person gets assigned a seat in the venue.
  • Floor plans: assigning names to each room in the plan or showing the availability of each room for overnight guests.
  • Marking up a piece of art’s damaged spots.
  • Building inspections

In all of these cases, a FileMaker visual data-entry system might be easier for the users. It is visual, but the data is added to or edited from a table in the custom app. That’s pretty powerful.

Taking it even further

GoDraw3 can do even more:

  1. Since the picture is a simple JSON object, not only could the pictures update/add records, but the record information could update the picture. In my example above, let’s say the doctor changes the status of “Left Shoulder” from “broken” to “Fixed” in the portal there. That update triggers a script that updates the JSON of the drawing object tagged with “Left Shoulder”. In this scenario, the picture would have to be opened and saved, but the action of adjusting the value in the table COULD update the picture.
  2. Snippets in GoDraw3 are drawn objects on the canvas saved as JSON. These snippets can contain tags. So a FileMaker developer could create pre-tagged objects and store them in the app. During the exam, then, the doctor could access these snippets and place these pre-tagged objects on the canvas as needed.

FileMaker visual data-entry: Nothing but FileMaker

GoDraw3 is a FileMaker drawing tool. However, since the tool is native FileMaker, we can use our FileMaker skills to create a FileMaker visual data-entry system. And we can use our clever brains to come up with even more possibilities with this tool. FileMaker’s uniqueness allows us to do anything we want with the tools given. GoDraw gives us an additional tool with which to make the best custom apps possible for our clients.


We are excited to see and hear of what awesome scenarios the community comes up with with GoDraw. If you’ve played with the demo and have thought of a cool scenario for visual-data entry, let us know in the comments below.

Learn more about GoDraw3 and download the free trial. Give it a spin and see its awesome power.

If you want, check out the sample file. Download it here.

Welcome to GoDraw3: The FileMaker Drawing Tool.


GoDraw3 is a powerful FileMaker drawing tool. Its native FileMaker features gives freedom to a user and flexibility to the developer of the custom app.

Freedom for the User

There is a lot of freedom for a user of GoDraw3 to draw images and store them in FileMaker.

Any user is able to:

  • Create a brand new image or draw on an existing picture.
  • Use drawing tools such as a pen or shape tool inside GODraw3’s drawing canvas.
  • Save the image in one of four possible formats: .png, .jpg, .pdf, or .svg format and use these formats for other purposes.
  • Open an image and re-edit the drawing.
  • Use standard shortcuts to speed up the workflow.

Flexibility for the Developer

GoDraw3 is all native FileMaker.

FileMaker Drawing: All Native

The drawing canvas. All FileMaker buttons, scripts, layouts and other objects

Even though the drawing part of tool is a JavaScript application running in a web viewer the developer has complete control over the implementation and customization of this app. Here are some of the 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 toolbars buttons and other UI elements is all done in FileMaker, so you can completely change how it looks just using FileMaker Layout mode. Don’t want users to create Text, just delete the button. It’s up to you.
  • The buttons all run FileMaker scripts that eventually tell the GoDraw canvas what to do. Once you learn how those scripts work you can customize the heck out of what they do.  You can have buttons that only make blue circles, or Red Rectangle, or insert an image of your Han Solo action figure. You get to decide.
  • The image is stored three ways:
    • in the container in a format chosen by the user (.png, .jpg, .pdf)
    • in a text field as an .svg
    • in a text field as a JSON object
  • JSON is the perfect data format for storing the edited images. With FileMaker’s built in JSON functions you create and parse entire documents if you want.

Because of the native nature of GoDraw3, there are plenty of possibilities for customization. GoDraw3 is completely open a developer to do with it what she wishes.

The Best FileMaker Drawing Experience

GoDraw3 is the best way to draw in FileMaker, saving the image and then editing it later. We’re excited about the potential. We have a lot of thoughts on how it can be used, and we will be sharing those over the next few days. Stay tuned to our blog to learn:

  • Specific use cases for which GoDraw3 would be great.
  • How to fully customize this tool for your custom app.
  • The techniques built into the app.

Learn all about GoDraw3.

Download it for free to try it out. The demo comes fully functional, but does contain a watermark on the drawing. So give it a spin and see how easy it is to draw in FileMaker.

I’ve been thinking a lot about FileMaker security. The topic comes up at least two times a day on the community forums. Bets are made, files are cracked in those bets due to the lack of security, and the conversation continues. It is a big topic, and one, I think, doesn’t get as much attention as it should. My attempt to remedy the lack of attention problem is one where I develop a FileMaker security model on an app of mine.

Choose your path

Wise people have schooled me in this part of development: it really is a matter of how much FileMaker security you need. A file of your favorite cheeses might not need so much, but others, like the storing employee HR information, requires ultimate security.

FileMaker security can be thought of as a game of deciding who a person  is and what they can do.

It is kind of like a video game ( a time-sucking past-time for me). I need to level up my character with certain skills or spells or weapons and armor in order to progress through the game. If I don’t care about beating that big bad monster around the corner, I don’t need to attain the proper level or attributes to beat it.

My level needs

So I sat down to think through and plan out the security model for a custom app of mine. The simple file I put together was to test out a mathematical formula for creating a Sudoko puzzle. I wanted to give it out, but I learned it from a book on magic tricks (one of my oft-ignored hobbies). Fearful of my life if I broke the magician’s code and revealed the secret, I held onto the file.


I needed to level up my app’s security to prevent some Josh person from breaking in and discovering how the formula works. Here’s what I decided on:

The user should be able to do

  • Log in with a username and password
  • View layouts and fields
  • Run scripts
  • Enter data into fields
  • Print!

The user should not

  • Have access to seeing a script run in debugger.
  • Have access to viewing a script in the script workspace (to see how the formula is run or to see how I wrote the script)
  • Edit the layout.
  • Open manage database.
  • Break into it from another file.
  • Export the data–I don’t want them to see how my fields are set up and get a clue on the scripting.

That’s top-level security right there!

Leveling up FileMaker Security

I tackled these level-up needs as follows (in the File / Manage Security menu):

Set up a new privilege set

I created a privilege set from scratch just to walk through the controls in this area. You can see the settings here.

FileMaker Security custom privilege set

My custom privilege set: User

A newly-created privilege set has absolutely no access granted. All boxes are not checked, and all the Data Access and Design drop-downs say “none”. That fact is something to remember, and it is a quite opposite of creating a new file, where that action gives full access to everything. So I had to go through each line to make sure I had the correct settings.

For the Records Access, I chose this:

FileMaker Security: Records Access Settings

Records Access Settings

Like the general settings, these start with “no” as the choice. I had to update each one as necessary.

For a moment, let’s review the choices for these settings. You have three: Yes, No, Limited. The first two are easy but the third one requires some thought. We’ll explore this in a later post, but it is a place to set a calculation to determine the access. For example, I could say anyone who’s first name is “Josh” has no access to the records in a table.

I’ve set up a new privilege set. Now I have to work on the accounts and login.

Set up the account and login

I created an account called “user” with the password “sudoku_’user’* and gave it the privilege set created above.

Next, I set up the Admin account to have a password (I won’t tell you what it is).

Finally I removed the ‘auto-login’ feature found in the File Options of the File menu.

*Note: I realize the password above is not very secure, but since many folks will download this file, I didn’t want to have to give a unique account and password to each person 🙂

Pause and Assess

So far my set up has been pretty good. I’ve taken care of both the ‘who is the person logging in’ though the account creation and ‘what she can do’ by setting up the limited privilege set. But now I have to remove “God Mode”.

God Mode – get in from the side

Another step in my leveling up is to remove what I call “God Mode.” In video games, the concept of “God mode” is the ability to get in and do whatever you want using a cheat code. In FileMaker we don’t have a cheat code, but we do have a sort of God mode. I can create a new file, call it “GodMode.fmp12” and I can set up an external reference to the Sudokou.fmp12 file if I can get to that file, whether it is on a machine or on a server.

In a separate file, I can create access to another file

In a separate file, I can create access to my ‘secure’ file.


With that reference created, I can get in by adding a table occurrence of Sudokou.fmp12 in GodMode.fmp12. Now I have access to fields, tables. GodMode.fmp12 has access to the scripts, the very scripts, in my case, that perform the ‘magic’ of creating the puzzle. I can write a script to perform “Create Sudoku” in the Sudoku file, debug it and see how it works.

Access to my Sudoku scripts using “GodMode”

God mode is powerful.

Disabling God Mode

Preventing God from accessing my Sudoku file is easy, but it is a setting a bit buried away in the FileMaker security settings. It is “File Access”.

One little checkbox removes God Mode.


This simply says that GodMode.fmp12 needs full access privileges of Sudoku.fmp12 to access the file.

When GodMode.fmp12 tries to access Sudoku.fmp12, this message pops up:

God Mode privilege is challenged

Failing to enter the Full Access account and password of Sudoku_Security.fmp12 will not allow GodMode to have access to the file. No access means no access to fields or scripts.

Optional: Remove Full Access

A hacker can do a lot of damage if they have Full Access username and password. So we can get rid of it. In FileMaker Pro Advanced, in the Tools / Developer Utilities, there’s an option to remove admin access permanently. That means that once stripped, the file cannot be edited as it previously could. It’s worth doing, but not always necessary. If you keep tight control over your password and don’t write it down on a post-it note and pose for a picture next to the note, you should be fine.

Other Security Measures

A final step in leveling up the security of your app is: Encryption at Rest, or EAR as we developers call it. This feature, again found in the Developer Utilities, actually encrypts the physical file.

EAR requires a user to enter a password to decrypt the file before it can be opened.

Without encryption, a hacker could open the file in a text editor and gain some knowledge possibly about the file. It might be worth trying it out.

My file isn’t encrypted, but when I opened it in a text editor, I couldn’t make heads or tails of it.


Security is such an important part of FileMaker development. We’re working with real data and valuable data (okay, even a database of cheeses can be valuable to someone ). So it behooves us to find the right level of security for each and every system. For my file, available below, I had to make sure that you couldn’t get into it, so I took proper steps to ensure that. We should do that for each of our files. WE should level up our file to the best security for our particular needs.