With Claris FileMaker 19, there’s a new world of power opened for us in using web viewer widgets inside our applications. We can create and use calendars, tables, lists, date pickers, charts, data trees, data maps, and thousands of other widgets. With Claris FileMaker 19, there’s a whole lot more power given to the problem solver with JavaScript in FileMaker.

The Problem

The most obvious problem with using JavaScript in FileMaker is learning JavaScript. The language, though developed to be a beginner language, has become complex. There’s lots to learn. There’s concepts, techniques, tricks that a web developer spends years learning. A JavaScript developer will spend most of her career learning, refining, and understanding JavaScript.

We don’t have that time. We don’t have time to watch many of the hundreds of videos out there on JS or even the entire courses. What we need is to find that which will help us in our FileMaker work now.

The solution?

JavaScript in FileMaker

This learning path is all about getting a FileMaker developer using JavaScript in FileMaker in as little time as possible. This thought is not crazy at all. In all the work I’ve done over the past five years, I come back to a few JavaScript concepts and techniques over and over again. The language may be big, but the parts of it we need as FileMaker developers are well defined and smaller than the entirety of the language.

Think of it like a Entity Relationship Diagram: FileMaker on the left, and JavaScript on the right. The word “in” is the relationship. We can look at the JS language through the ‘in’ relationship and see only the parts of JS that is useful right away.

The learning path takes us along five well-trod workflows, that which  we do already in FileMaker. They are:

Five workflows: Perform Actions, Manipulate Data, Load Code, Update the Display, Retrieve Data

This path explores the JavaScript techniques and concepts that perform these five workflows. In Manipulating Data, for example, we’ll look at how to reconfigure an array of data from FileMaker for use in a JavaScript library.  In the Performing Actions workflow, we’ll explore how to create functionality in JavaScript and how to call the function from inside the web viewer or from FileMaker.

There is some technical stuff to know, for sure. We’ll need to understand how to style elements in the web viewer or what the window object means. None of this knowledge is beyond any FileMaker developer.

The Path for Everyone

This is the JavaScript learning path that I suggest any FileMaker developer take. As Cris Ippolite mentioned in a Claris Engage panel recently, this path didn’t come from some professional JavaScript developer. It came from someone (me) who first asked what one can do do with the web viewer, sat down to study how to organize JS libraries in FileMaker (and which would be useful in FileMaker). This path was marked through writing about JavaScript and using it and answering questions in the community.

Taking the Path

Very very soon we’ll have a complete set of instruction and practices around these five FileMaker workflows. Any practices we do will involve FileMaker every step of the way: The new JavaScript functionality, the new Execute FileMaker Data API script step, and the web viewer itself. We’ll build sample projects, and I’ll challenge you to construct this in (a copy of) a current app you’re developing. We’ll also review documentation, books, blog posts, and others’ videos on JavaScript so you see the whole world from the safety of the current path.

Alternatively, you can take the specific JavaScript concepts and techniques and extract from other JS courses what you need to know. Wes Bos is a great web-development teacher (he literally says “I’m here to help you become a really good web developer.”), and I encourage you to review his videos on the specific skills that we have defined in the path. This mode of transport will not be specific to FileMaker, of course, but you can get a lot out of any JavaScript course that will help you in FileMaker.

Onward

Jump on this JavaScript learning path and work with me and hundreds of other FileMaker developers to learn JavaScript in FileMaker. Follow this official Twitter account (@JS-learnjsforfm) and of course, stay tuned to the site for more information and the complete instruction set.

Click here to view a larger version.

On this very afternoon, the day before Claris Engage 2020, we pause to contemplate all that’s going to happen in the next few days. While we will miss seeing old friends or meeting new friends in the hotel lobby, at the fireplace, or sipping on a cocktail at the hotel bar, we are excited about what’s to come.

There’s a lot in store for this short week, and so this is the opportunity to let you know of four important events on our side. Here they are:

Engage with Us and the Community

As we’ve written about before, since we can’t gather in person, we will gather together with new and old Claris friends this year in a Slack Workspace called Auto-Enter. Please join us and meet someone new.

Geist Interactive Sale

Our award-winning dev tools and addons are on sale for you as of right now. Stop by the website to pick up FMPerception, LedgerLink, Otto, or any other tool to help you out. With great products comes great service, and we’ll be here for you to answer questions and support you along the way. The sale applies also to subscription renewals.

There’s no code necessary. Just add items to your cart and you’ll enjoy the savings!

New Product: FMComparison

From Dave Ramsey, the maker of the award-winning dev tool FMPerception comes FMComparison. It’s the fastest diff-tool out there. Simply run the “Save a Copy as XML” command (FileMaker 19 only) on two versions of the same file, and you’ll see all the differences of the newer version compared to the old. It’s an amazing tool with lots of possibilities.

The beta of FMComparison is out now, and those with a valid license of FMPerception will be able to use this tool for free. So join the beta and let Dave know your thoughts.

Geist Interactive Presents!

In two sessions on Tuesday, August 4, Todd will present a demonstration of add-ons and some JavaScript. This will be an introduction to: Add-ons, the new JavaScript functionality, and the new Execute FileMaker Data API script step. Jeremy and Todd will join Claris representatives as part of the Q&A portion of the first session. If you have questions you’d like answered, please send them to support@geistinteractive.com or ask them tomorrow during the time.

The sessions are:

FileMaker 19 Under the Hood: Javascript & Add-ons: (Aug 4, 10:15-11:15 PDT)

Panel: Add-Ons & Open Platform: This Changes Everything: (Aug 4, 12:00 -12:45 PDT)

You can still register for these sessions. Don’t miss out!!

We look forward to the week of excitement in the Claris Community! It’ll be fun and busy and exciting. The next few days are going to fly by and will be incredibly inspiring. We can’t wait. Oh, and FYI: Since the excitement happens Tuesday and Wednesday, we will not be holding office hours this week. Please take the last part of the week and reflect on Claris Engage and watch the awesome on-demand videos.

We at Geist Interactive are thrilled to be a part of the first ever Claris Engage, in this year 2020. Though this first event is a virtual one, we will be part of the the event in the 1’s and 0’s that make up cyberspace. There’s a lot going on, so let’s take a moment to review and point out a few things:

Here’s a rundown of what’s happening.

The Main Channels

Chat with Us & Others in the Community

A Slack workspace where you can join with fellow virtual Claris Engage folks (the folks aren’t virtual, the conference is hosted in the cloud). It’s like a “Watch Party” for the main event. Come and hang out with us and others.

The Lobby Bar

Engage Live

Vendors

The Main Event

August 4th and 5th, Claris is hosting the free Claris Engage. That’s amazing. As I considered this idea, spending two days online engaging with others in the Claris Community, I see a lot of possibilities:

  • At home, in my comfortable office with all my gadgets and toys.
  • I can take a break and go freshen up without anyone noticing I’m leaving the session.
  • I can get lots of sleep.
  • There’s very little walking.
  • And for me, the pool is way less crowded.

Of course, there are a few drawbacks:

  • I won’t be able to eat delicious and generous foods. I can’t say “This is vacation! Three plates of desserts doesn’t count.”
  • I won’t be near other FileMaker folks. No one wearing a badge lanyard will be wandering around to whom I can say hi, or at the very least, give the ol’ subtle nod as we pass each other. You know, maybe I’ll make my three dogs walk around the house with lanyards from past events. Hmmm. . .
  • I don’t have an excuse to hang out at the bar at all hours of the day.
  • And, most importantly, I won’t get to connect to friends, nor will I get to make new ones as easily this year.

The Virtual Sessions

Anyway, the main event, on those two days (and the same two days that the Auto-Enter space will be available) Claris is hosting live webinars with Claris folks and Claris partners to talk about higher-level concepts with this new open-release platform. I’m sure we’ll hear some detailed technique or so, but these sessions are conceptual in nature. They center around performance, and ‘low-code’, design excellence, user experience, and add-ons, to name a few. The Claris leadership will join us virtually in our homes to answer our questions we have about the platform, the future, and (possibly) their pets.

I looked at the session list for those two days. There’s too many to point out–they’re all very good sessions and topics. I look forward to hearing the panel of experts on each one share their conceptual understandings and forward-thinking views of our platform.

But if I must point out a few, here’s what you MUST absolutely ‘attend’:

  • The Opening Keynote: Delivering the Promise of Digital Transformation: (Aug 4, 9:00 AM PDT)
    • Here’s where we get to here CEO Brad Freitag and the leadership team talk about what’s new at Claris and their path and vision forward.
  • FileMaker 19 Under the Hood: Javascript & Add-ons: (Aug 4, 10:15 AM PDT)
    • Todd is part of this panel. They’ll discuss the newly-added add-on functionality and the newly-enhanced JavaScript workflow in the platform. Todd will demonstrate how add-ons are built and the use of JavaScript in those add-ons.
  • Driving Customers towards Modern Design Excellence: (Aug 4, 2:00 PM PDT)
    • This panel is made up of experts in design, including Alexis Allen who talked with us early this year about Workflow Based Design. I personally hope they mention JS add-ons in their discussion 🙂
  • Vision Forward: Claris Platform Futures: (Aug 5, 12:00 PM PDT)
    • It’s a tradition at Claris conferences to see some peek of what’s coming next in our FileMaker and Claris Connect apps. We developers all look forward to this, and we usually work to secure a seat up front to see ‘extra close’ what’s new. This year, we all get front-row seats. Robert Holsey and the other project managers will put on their best smiles and drum up their passion for the platform for us all to see.
  • Looking Ahead to Emerging Technology: (Aug 5, 1:00 PM PDT)
    • I’m interested to see what is emerging from the Wedge (or virtual Wedge, as the case may be) in the form of new technology. We’re all so used to the FileMaker Application. What’s next? I hope a robot, of some sort.
  • Closing session: Awards, Recognition and Our Path Forward: (Aug 5, 4:00 PM PDT)
    • The closing session is always a rousing feel-good session that sends us back to our work (since we’re not travelling at all this year). The awards and recognition lifts our tired spirits and energizes us to continue to solve problems for our clients. The panels, this year, I’m sure will inspire, but these closing remarks by Claris is meant to set us on their path forward. So stick around for these!

Other Events

Immediately after the two days of sessions and panels, the On-Demand sessions will be released. I’ve got two sessions that will be part of this release, so stay tuned to this post and our Twitter for those announcements.

“See” you “@” Claris Engage

We hope to see you there ‘at’ Claris Engage. Please stop by our hang out area and say hi to us and others in the community. And please ‘stop me in the hallway’ and introduce yourself if I’ve not met you yet. Show me your JavaScript work with which you’re tinkering, or ask me questions about JavaScript.

Todd and I talk about FileMaker Primary Keys today in the Context Podcast. Here’s the episode. Listen to it here.

And here are the highlights.

Well-Discussed Topic

The topic of FileMaker primary keys gets talked about a lot in the community, and indeed I asked about it long ago.

The Basics of FileMaker Primary Keys

Primary keys are simple to understand, but implementation takes nuance, and there is a lot to talk about. The nuances sort of come out of our understanding of primary keys.

The simplest database definition: A field (only one Field in FileMaker) that contains a value that uniquely identifies a record in the database in a table in the database. A primary key is an address, sort of. In other databases, you can have multiple fields to be defined as primary keys. In FileMaker, we only can use one, and that’s okay because of the platform we’re in. It’s not that necessary to study other platform’s use of primary keys, but it’s good to know others are out there.

The book Database Design for Mere Mortals by Michael J. Hernandez talks about primary keys, and defines it as being unique across the whole file. We as FileMaker developers can do that, but it’s not necessary.

Primary Keys NOT Supported in FileMaker

In fact, FileMaker doesn’t really have the strict support of primary keys. Primary keys are supported in other databases, so the database engine knows there’s a relationship between the primary key and the foreign key. You have to pick a primary key in other platforms; FileMaker doesn’t require them. In fact, for years, no real mention of the idea of primary keys was mentioned. Starter solutions had field names such as “Match Field”.

A Starter Solution using the primary key “Contact ID Matching Field”

Ways to Generate FileMaker Primary Keys

We make a field be a FileMaker primary key by setting it up as unique and by using it in relationships. Since FileMaker 17, we’ve had default fields (updated in FileMaker 19) which identifies a field in that utility set as a primary key in the XML.

The Get(UUID) function ensures that each primary key value will be unique, even across the whole file. There’s certainly a difference between in-theory and in-practice, and we can be assured that FileMaker will do its best to ensure primary keys are unique. Todd has done tests of creating millions of records and never got a duplicate UUID.

FileMaker Primary keys can be serial number, auto enter, where FileMaker increments the next value by a number. There’s a lot of problems, namely that importing data into a new version of the app could cause issues in that the serial value doesn’t get updated so the next value would not duplicate any existing value. Set Next Serial Number script step helps in this regard, but it’s extra work.

There are custom functions that create primary keys as unique values. The math behind the calculation ensures a very low chance of getting a duplicate.

Get (UUIDNumber) again will not give you a duplicate in practice.

Natural Keys ≠ Primary Keys

Readability of the FileMaker primary key is nothing we should consider. Primary keys shouldn’t mean anything to developer or user, nor should they be visible on a layout. Let your strict relationship logic rely on the math of the UUID functions. It’s really not a value in a field; instead, it is a link.

Natural keys are unique keys that visually identify a record. Student numbers, social security numbers, etc. are natural keys. And these shouldn’t be used as primary keys. Natural keys are valuable for integrations. They shouldn’t be used for relationships. Natural keys are great, and use them. But just for visual identification.

Switching Key Types

If you already use serial numbers as primary keys, you should consider switching to using Get(UUIDNumber) as your method of creating keys. There’s an advantage: the type of field doesn’t have to change. If your last serial number is 45, and the first UUID Number is 893928392919281929 . . . there’s no issue; relationships will still work.

Another reason for switching from serial numbers is syncing. Without UUIDs, syncing will break. Records created on Device 1 and device 2 can have the same serial value in the key, and that’s going to be a major problem when both devices’ data gets synced to the main file.

Does Every Table Need a Primary Key?

Every table doesn’t need a primary key–look ups, value list tables, etc. However, there’s not really a problem to have primary keys in every table (in fact, the default fields ensure this to be the case).

There’s a look up kind of table, one that holds information in it about a unique record. A Country Code table, for example, could use “US” as a primary key since that is unique to the table. As long as we’re not using “US” for relational logic, it’s okay. Look-ups are different.

Primary Key Implementations

FileMaker Primary keys are indexed. Text keys have two indexes, and that can increase the size of the file. But this is rarely a problem.

Default Fields tag a field as a primary key, and those are needed for Add-ons. We think Claris is moving towards supporting primary keys.

Naming FileMaker primary keys: this is up to the developer, but just be consistent. We use <<TableName>>_ID for the primary key.

The Data Migration Tool auto-increments the serial number.

Using Primary Keys with Integrations

Using primary keys with integrations is tricky in many cases. Our product LedgerLink handles the issues, and its method came from Todd’s extensive tinkering with the idea. Here’s a brief summary:

Integrations bring to the table a more complex problem. As far as primary keys are concerned, It is tempting to use the FileMaker primary key as the link between an invoice in Quickbooks Online and a FileMaker app, such as LedgerLink. After all, QBO has all the invoices and so does the FileMaker app. The problem comes in restoring invoices from QBO to your FileMaker app. All the primary keys you used for the links will be gone (the records are deleted) and as invoices are imported into the FileMaker app, new primary keys will be generated. The link breaks.

So the QBO keys (established in QBO and never changing) should be used as the link. Easy? Not so fast. . . In QBO, there is no such thing as invoice lines in the API we get back. Lines of an invoice are packaged up with the invoice, and there’s no foreign keys for each line.
In FileMaker we need primary keys and foreign keys to set up the proper UI and relationship. We can’t use the QBO Ids.

So we really need both. We need to build a system that maintains the link for each invoice to QBO through its IDs but also use Primary keys and foreign keys to build what we need in FileMaker.

Thinking about Primary Keys in Practice

Generally, we have to think, when using Integrations that become your source of truth and from which you might have to restore data into FileMaker, you have to consider this idea and work to maintain the links between the integration’s end point and your FileMaker apps. There’s a lot more; maybe we’ll explore that in a future episode or blog post.

Over the three years I’ve been here at Geist Interactive, I’ve shared quite a few web viewer widget demo files. They were meant to show what is possible in FileMaker using JavaScript. They were meant to inspire. And they worked well. In all cases, useful UI elements were added to a layout; audio players, C3 Charts, and date pickers are among the examples.

More For Me to Do

Now that we have FileMaker 19, I (slowly) am going through the files and am updating them for FileMaker 19. In most cases, the old file would work in FileMaker 19. However I wanted to get them updated because the functionality in FileMaker 19, the solves a lot of problems with web viewers we’ve had for ages. It was good practice, and, as it turns out, is a good demonstration. So here’s my first attempt using the Perform JavaScript in a Web Viewer step. I’ll do so using the audio player.

Before and After

Here’s what it looks like before FileMaker 19:

And here’s the widget using FileMaker 19.

Both widgets still play a file in a container field. Both still toggle the mute of the player, and both update the speed of the playback.

FileMaker All the Way!

There is a subtle and super-powerful difference. In the former image, I’m using HTML buttons to control the playback. In the latter image I’m using FileMaker buttons and scripts to run the playback, the mute, and the speed.

The difference is that I know FileMaker much better than JavaScript, so I can use FileMaker to completely control every part of this. I can control when the file gets played, when it gets stopped. I control its playback speed, and I even can control which file gets loaded.

Since a FileMaker developer can now control these functions using Perform JavaScript in a Web Viewer, she doesn’t have to rely on a JavaScript developer (or me) to update the code to, say, play it back at 1/2 speed–the JS function attached to that button is not set to use 0.5 as a speed. As the author of this demo file, I don’t have to plan for EVERY use case all the people who download this might want. I can set FileMaker scripts and script parameters with some basic info and let anyone change a lot about this.

So I’ve updated the audio player to use to use Perform JavaScript in a Web Viewer. The following video shows the steps I took to update the widget. My goal was to demonstrate how to use the new FileMaker features so that anyone can take this file they previously downloaded and update their audio player. Extracting the concepts, you can apply the steps I took to any file.

My First Steps

So I present to you my first update:

In the above video, I just focused on using FileMaker scripts and buttons to control the playback. And this is how I did it.

I took this normal JavaScript function that was run by a button:

function playPause () {
  wavesurfer.playPause();
  var element = document.getElementById("play");
  var btnText = element.innerHTML;

  if (btnText === "Play") {
    element.innerHTML = "Pause";
  } else {
    element.innerHTML = "Play";
  }
};

and made these changes:

  • Exposed the function to the global window object
  • Removed some functionality that updated the HTML buttons

Here’s what it looks like now:

window.playPause = function () {
  wavesurfer.playPause();
};

The window. exposes the function to the global window object and, in effect, exposes it to FileMaker so that the Perform JavaScript in a Web Viewer step will call the function.

Now I wrote a script that calls Perform JavaScript in a Web Viewer:

And now a FileMaker button can play or pause the audio file.

Cool.

More Coolness

As I was editing it, I realized I could do one more thing: use FileMaker script to load the file into the widget. Todd demonstrated that in the webinar he and Claris recently shared. He used the Data Tables library, demonstrating just the end result: how to load the data.

I was inspired by this demonstration to set it up for the audio player. As a result I can use a FileMaker script to load ANY audio file (as base64) into the widget to play, again using the step Perform JavaScript in a Web Viewer.

Isn’t that even more cool?

Here’s the video showing how I did that.

So there you have it. A newly updated version of the audio player for FileMaker 19. If you’ve already downloaded this file before, please take a few moments to watch the video and to follow my steps in the conversion process. It won’t hurt and you’ll learn a new skill.

If you don’t have FileMaker 19 yet (gasp!) feel free to continue to use the old version.

Here’s the newest version, all ready for you in FileMaker 19. But, again, give what I described above a try before just using this one :).

In my next post (written here on a Saturday night) I’ll update the date picker using more FileMaker 19 functionality.

Geist Interactive teamed up with Claris to produce a webinar focused on what JavaScript Can do for your FileMaker Apps. We also discussed how JavaScript fits perfectly into the FileMaker 19 Open Platform Release. Below are a list of resources, next steps and other online resources for people who attended the webinar.

Here’s the video:

Geist Interactive teamed up with Claris to produce a webinar focused on what JavaScript Can do for your FileMaker Apps. We also discussed how JavaScript fits perfectly into the FileMaker 19 Open Platform Release. Below are a list of resources, next steps and other online resources for people who att

Webinar Resources

Here are links to all the libraries we used in the webinar.

  • DataTables: Our number one library for creating a list view with a lot of built-in functionality. Check out Todd’s demo file.
  • Apex Charts: This is a cool, smooth, and modern charting library.
  • Kanban: The way we built a Kanban board as an add-on for FileMaker.
  • FullCalendar: The best and most widely used calendar JavaScript Library.
  • TUI Image Editor: A highly-functional image editor JavaScript Library.
  • PSPDFKit: A commercial JavaScript library that allows a user to annotate onto a PDF.

Geist Interactive Examples, Demos and Learning Tools

  • Jeremy’s JS Playground: A file we put together to lead the training session at DevCon 2018 and 2019. This is the OLD file. Download the next one if you wish to have the updated version.
  • JS Learning Path: A series of familiar FileMaker use cases and exercises in JavaScript.
  • DataTables Config file: A demonstration of using DataTables without knowing any of the JS. You can create settings in a FileMaker record, and use those to create a configuration.
  • DataTables: A list of all the blog posts we’ve done on this library.
  • C3 Charts: Another charting library. The post provides a start and end file and steps on how to integrate.
  • Audio Player: A cool small library to play an audio file in a container field.
  • FileMaker & JavaScript: Additional videos and posts about our JS study.
  • FileMaker & Javascript Training Session Redone: Jeremy posted videos and the files he used during the 2019 DevCon Training Session.

From the Claris FileMaker Community

Online Learning

Documentation

We’re Here to Help

If you have any questions about these resources, if you want to chat about JavaScript, learn JavaScript, or have us develop add-ons and integrations for you, reach out at sales@geistinteractive.com. We’re here for the FileMaker community to power up their apps with JavaScript.

This post is a summary of an episode of The Context Podcast, episode 40, release date 6/16/2020. In this episode, Cris Ippolite joins us to talk about Shortcuts and NFC. Those two features are the stated topic, but, of course, we touch on a lot of other things. So here’s a summary of what we discussed.

Please take a moment to subscribe to the podcast at Apple Podcasts or wherever you get your pods. There, you’ll find great technical episodes as well as our FileMaker Origin Stories series.

Outside of a Web Viewer

Cris shares a surprising finding about some JavaScript add-ons. He discovered, while playing with his demo file for LinkedInLearning, that you can get a part of a JavaScript input field to extend past the boundaries of the web viewer (on macOS only). The color picker-type input in question actually could also cover a FileMaker layout object as well. Cris was startled by this discovery.

Todd reminded us that inside a web viewer there’s a browser: Safari on MacOS, and IE 11 on Windows. He explained that control field types in HTML are provided by the operating system, not the web viewer or the browser itself. You can add styling to these control fields, but if you use the native input, the OS renders the color picker, so the color picker is ‘allowed’ to be outside the web viewer.

WebViewer Widgets

We’ve decided there are three types of web viewer widgets: Fullscreen, “Sneaky”, and Computational. We’ll talk about this more in another blog post, but here’s the quick definitions:

FullScreen Widgets

These widgets cover almost the entire layout. Users interact with the widget wholly. FileMaker buttons can be on the layout, and those buttons can interact in some ways with the widget.

Sneaky Widgets

These widgets are more subtle. They’re simply treated as objects on a layout, incorporated into the workflow-based design of the layout. These widgets sit alongside other objects, including fields.

Computational Widgets

These kinds of widgets are simply used to harness the power of the JavaScript engine and JavaScript libraries to return a value back to FileMaker. Users do not interact with these widgets. Scripts do. For example, if you wanted to find the first Thursday in the month of June, you could do that easier with a JavaScript library.

Machine Learning

As always, Cris is playing with FileMaker in prep for his courses or simply discovering new features. He played with an app called Hotdog/Not Hotdog to demonstrate this new feature. Check out his video.

Shortcuts

Before talking with Cris, I wasn’t convinced Shortcuts were a necessary thing. They were cool, for sure, but I was searching for reasons why I’d use these in a FileMaker app. And I thought ‘shortcuts’ referred to ‘Siri’. Cris schooled me.

This is a bulleted list of details Cris and Todd shared about Shortcuts.

  • Cris first did a session in 2016 on URL Schemes, where apps talk back and forth to each other on iOS. He profiled an app called Workflow.io. This app used to create url schemes between apps. This app turned into the Shortcuts app.
  • In FileMaker 19 we can ‘donate’ FileMaker scripts to the Shortcuts app. This allows us to set a Shortcut in the Shortcut app to run a FileMaker script.
  • Go into FileMaker Security, and enable the extended privilege “Allow URLs to run FileMaker scripts” for each privilege set.
  • You can pass a parameter to the FileMaker script that runs from a Shortcut. This is the same as the fmp url, which Cris suspects is what’s happening under the hood.
  • Transfer the FileMaker app with ‘donated’ scripts to FileMaker Go, open the app and create a shortcut for each of the donated FileMaker scripts.
  • Shortcuts are specific to each device, so even though a script is enabled to run via a shortcut, users of the app on iOS will not automatically be able to use the shortcut.
  • If you are using iCloud to share across devices, you can share a shortcut to all of your devices. This gives you a URL. This could actually be built into a FileMaker app and run onOpen: Do you want to install this shortcut? You can even text the URL to someone.
  • There is a security setting in iOS “Allow Untrusted Shortcuts”. This needs to be enabled.
  • Shortcuts simply run FileMaker scripts. You still have to manage security and permissions in FileMaker.
  • You can create an action in the Shortcut app that runs before the FileMaker script runs. The action can be a question. A user’s response to the question (a voice command) can be sent back to FileMaker as a parameter.
  • FileMaker Go doesn’t have to be open for this to work. Shortcuts will open up FileMaker Go and authenticate if necessary.
  • Cris has a great example: his Dog-Walking App. Check it out.
  • Record control is very important: If you’re using voice control, you need to make sure the record data gets committed. You might even want to use transactions to ensure the data gets saved.
  • Shortcuts don’t have to be just Siri. Shortcuts can be location or proximity based, they can be set on the home screen as buttons on the screen or the watch.
  • Todd brings up a good point: this and other features of FIleMaker 19 blur the lines of how to interact with FileMaker apps. We’re even more free from just having to enter data via a keyboard and mouse.
  • If the file is hosted and not found during the shortcut run, you can get the shortcut to let you know the file is not available.

Location-Based Triggering

There are many different types of location based triggers: Geo-fencing, iBeacons, NFC, and Barcodes

Geofence

  • Polled from the Configure Region Monitor Script Step.
  • Have a latitude and longitude and radius setting to determine coordinates of the ‘box’ that, when crossed, the chosen script should run.

iBeacons

  • Polled from the Configure Region Monitor Script Step
  • Run a script when you get near a physical object in the environment. The range is less than 30 ft. Each iBeacon can be set to trigger a script.
  • There’s tons of examples of using iBeacons.

NFC

  • NFC uses the script step Configure NFC Reading.
  • NFC deals with Near-field Communication. Apple Pay uses this, as Apple went all in on NFC.
  • NFC has been around for a long time, over 2 billion NFC pieces that have been produced.
  • For an NFC trigger, the device has to be within four inches of the NFC tag.
  • NFC tags can be read and written to. We can’t write it in FileMaker (yet).
  • You’re telling a script to run when the NFC tag gets detected. The data stored in the tag can be brought into the script using Get(ScriptParameter).
  • Writing to NFCs is cheap and easy. Buy a bag of of them. Spread them around your home and do things.
  • Again: NFC further helps us to interact with the world.
  • NFC is started via a script. A little card comes up on the lower-third of the iOS device.
  • You can turn off the NFC polling with the timeout option.
  • NFC passes the polling to the iOS device. FileMaker is not trying to find the tag.
  • Cris thinks it will be possible to write to an NFC tag from FileMaker in some future version of the platform.

Tinkering with FileMaker

And finally, I want to reiterate the idea of just playing with this stuff. That’s a great way to learn, even without a specific use case in mind, though I’m sure one will come to you shortly. Cris and Todd demonstrate that by just tinkering with script steps and devices, one will pick up a whole new skill set. Yes, reading blog posts and watching videos is useful, but nothing is as useful as just getting your digital hands dirty. A while back John Renfrew and I talked about this very thing.

So give something new a try. Let us know what you tried and what you learned.

In part 1 of All That We Know on Add-ons, explaining all that we know about this new feature, we talked about how to create add-ons that lend themselves to UI widgets. Calendars, check box button bars, notification popovers, date pickers, timers, etc. all can be dropped into a custom app as they are. Sure you might need to attach some fields to scripts, but essentially these kinds of widgets are a complete package.

There are other types of add-ons that require a more extensive relational set up. That is, you might wish to build an add-on called “Notes” that consists of a related table of notes displayed in a portal. This add-on is meant to be installed anywhere in your file and in many different files. This add-on takes the place of having to build this table, the scripts, and the relationships over and over. Build it once. Package this as an add-on, and boom. Use the add-on many times.

In this post we’ll look at how to create this “Notes” add-on package, which, in database terms, requires a one-to-many relationship. We’ll also explain how to create a many-to-many relationship add-on, such as a “Schedule/ Classes” package.

Considerations

  1. We are creating add-ons from the ‘related table’ context. Since, in this post, we’re using the use case of “adding a notes package to a custom app”, our add-on creation starts with the Notes context (table).
  2. A package is one or more tables (among other FileMaker things). As you install the add-on, the tables inside the package get added to the schema once. Even if you place the add-on many times in your file, each instance will use the exact same table.
  3. Adding an add-on to a layout automatically creates the relationships between that layout’s table occurrence and the add-on’s tables, provided you’ve set up the package correctly.
  4. Remember: there’s a difference between ‘installing’ the add-on and dragging it to your layout. The difference is very apparent in these kinds of add-ons.

Yes. I know these points are a bit confusing. We’ll clarify them in due time, but I wanted to point these ‘issues’ out to you right away. I’d recommend reading the three considerations again and see if you get an idea of their meaning.

So let’s get packaging!

Creating Related Packages

A Related package is one that will be added to a custom app and be automatically related to some other table in your file. Again, our example is “Notes”. We’re going to illustrate this process with a child table that holds notes for each project in a Project table. This is our end goal:

In a new FileMaker file (called “Notes”) add any fields you want in the package to that Notes table. This table should contain a PrimaryKey field and a ForeignKey field. Here’s my simple example:

Right here we have to stop and explain something very important: the PrimaryKey field MUST be identified in the eventual XML as a primary key field. There’s no way to do this in the Manage Database UI yet. The only recourse we have is to use the defaultFields.xml setup that FileMaker uses for each new table.

Since this Notes table is going to be related to a “Projects” table occurrence, I need the foreignKey field here. Unfortunately I cannot give it a more specific name, like “ProjectKey” or something. Since this add-on is meant for many different scenarios, it’s impossible to specify the name pre-install.

Set up the Layout

The layout needs to have the __FMAddonTemplateDirectives_en name, as we learned previously.

To this layout add a portal. Since the context of this layout is the Notes table occurrence, and eventually this will be a related table, use the “Current Table” option in the portal-setup dialog.

Yes, this is how we create master/detail lists, but the portal is simply showing records from the current table.

Include the relevant fields and style it how you wish.

Also include any scripts you wish such as one to delete the related record.

Include the foreign key field (and its field label) on this layout and give the object a name with the following three parts:

  • A Relationship name: R1
    • Your name can be anything, but it should be unique for each relationship you build.
  • Separator: |
  • Table Position: RightTable

The ForeignKey object is then named, in this example: R1|RightTable

Grouping Objects

The add-on package process requires groups of objects so the XML can be generated properly. As we do in UI add-ons, we have to group certain items and leave out others. With a relationship-based add-on we have to do a bit more grouping. Here’s how to group objects:

Group the UI element–in this case, the portal–like normal. This is the element dragged onto the layout after add-on installation. By the way, you can group the single portal object by also selecting the portal fields in the grouping.

Group the foreignKey field with its field label. Name it carefully with the prefix __FMAddonDynamicRelation_. Finish the name by including the RelationshipName you gave the actual ForeignKeyField: __FMAddonDynamicRelation_R1

Yes, we’re placing a foreign key field on the ‘special’ layout. However, this object will NOT be part of the drag-on package. Its only purpose is to help the XML know which field is meant to be the ForeignKey field.

Create the Add-On

With your handy external file, create the add-on package. Quit FileMaker. Re-open. Your add-on should be available in the AddonModules folder inside the FileMaker Pro Extensions folder, and it should be ready for installation.

Here’s what the Projects file relationship graph looks like without the add-on installed:

At Installation, the layouts, scripts are added to the file. Likewise the Notes table occurrence is added to the RG.

Notice there’s no relationships added as of yet. Don’t worry. Those will be added soon enough. Can you reason why the relationships have not been added? Stop and think about it for a second.

Don’t read ahead!

Seriously. Stop. Come up with the answer first.

Here’s why: During installation the package is just added to the FileMaker file. The add-on package has no ‘idea’ (yes add-ons are almost sentient) which table occurrence to attach itself to. There could be hundreds of table occurrences in an app. Like an alien in a ship, however, the add-on lies in wait ready for a table to latch onto. The latching comes not during this process but during the . . .

Applying an add-on Phase

When you drag the add-on out to a layout, the add-on picks up which table occurrence it should attach itself to. Here I dragged on the Notes add-on to a layout with the “Projects” table occurrence context.

This is what happened in the relationship graph:

As a bonus (or not) this relationship checks the “Auto Create” and “Delete” options.

So that’s how you create add-ons with relationships, with simple relationships. There are caveats. So let me clarify those. Let’s start with this consideration:

A package is one or more tables (among other FileMaker things). As you install the add-on, the tables inside the package get added to the schema once. Even if you place the add-on many times in your file, each instance will use the exact same table.

This is key, and something to strongly consider:

When you drag an add-on to a layout, a relationship is created between the existing table occurrence and the table in the add-on. It will do this every time you drag the add-on to a layout of a different context. Observe:

I add a new table and layout called “Tasks”. The table occurrence is added to the relationship graph.

I then add the same Notes add-on to this layout.

Look what happens to the relationship graph:

What do you see? The Tasks table is now related to the Notes table. Let’s consider a few factors:

  1. Tasks and Projects are related to the same Notes table occurrence.
  2. Tasks and Projects are now related to each other.
  3. Tasks and Projects use the same foreign key field in the Notes table.

What do you think? Is this an issue or not? We certainly have our opinion, but we’re interested to see what the community thinks as well. Please leave your thoughts here or in the Claris Community forums.

Onward and To Be Continued

This is a long post; let’s leave this one at this point and pick up “Join Table” type relationships in the next post.

Modernize your apps with data visualization, maps, calendars and more.

Open up a new universe with Claris FileMaker apps and JavaScript. Learn why JavaScript is such a good fit for the Claris FileMaker 19 open platform. See several compelling business examples, and find out how you will be able to use JavaScript add-ons for things like kanban boards, calendars, photo editors, animated graphics, and more. The possibilities are virtually endless.

Best of all, you don’t need to know JavaScript

You will learn:

  • What JavaScript brings to the Claris FileMaker.
  • The advantages of FileMaker custom apps built with JavaScript add-ons vs. SasS alternatives.
  • How to get started with helpful resources.

Join us for this 45-minute webinar lead by Todd Geist, Geist Interactive, a Platinum Claris Partner. The presentation will include an overview, demo, and a Q&A session.

Note: this presentation will be in English only.

Date: Tuesday, June 23, 2020
Duration: 45 minutes
Times: 8:00 AM PT, 11:00 AM ET, 3:00 PM GMT, 17:00 CET
RSVP now:
https://content.claris.com/amr-webinar-fm-javascript-06232020-reg-8am

Times: 4:00 PM PT, 7:00 PM ET, 9:00 AM AEST (Wednesday, June 24, 2020)
RSVP now
https://content.claris.com/amr-webinar-fm-javascript-06232020-reg-4pm

The most recent release of FileMaker Pro, version 19, the Claris’ first Open Platform Release. Todd has already talked about this. In his post, he describes the ways in which FileMaker the platform is opened to other developers coming in to add functionality. We at Geist Interactive worked closely with Claris to build FileMaker add-ons for the platform–those add-ons we’ve all heard about in previews or heard about in podcasts (here and here). Here is everything we learned about how to create add-ons using the current FileMaker 19 release. We’ve wrestled with the process, found many issues, and have worked with Claris to fix those issues. So here’s what we’ve learned (or at least most of it; we’ll follow up this post with additional ones describing more details).

What is an Add-On?

An add-on is a package of FileMaker tables (including data–see the Data section to understand this), table occurrences, layouts, scripts, custom functions, themes, custom menus, and layout objects that work together to add additional functionality to a custom app. An add-on can be complex, like a Kanban board (using a web viewer, three layouts, and multiple scripts and multiple custom functions), or an add-on can be a simple collection of global fields and scripts that process credit card information. We’ve already seen even the simplest add-on of a button bar that displays a checked or unchecked icon. Pretty cool!

The Process

The following document explains how to create an add-on. The process, at its basic level, involves grouping a set of objects together on a defined layout and then running a new FileMaker 19 script step to package up the relevant items in the file as an add-on..

The end result of this simple process is an add-on that is added to the following application folder.

  • Library/Application Support/FileMaker/Extensions /AddonModules folder (on macOS).
  • AppData\Local\FileMaker\Extensions\AddonModules (on Windows).

Once added to this folder, the add-on will be available in the developer’s copy of FileMaker Pro and then installed into a custom app. From there the add-on will be available to everyone who uses the application.

Some Notes

  1. The file in which you’re creating the add-on must have a unique File ID. This is generated when creating a new file or by clicking “Reset All. . . “ button in the Manage > Security > Advanced Settings > File Access Dialog. We recommend creating a new FileMaker file each time you want to create a new add-on.
  2. The name of the file will be the name of the add-on. You can change the name once the add-on has been created, but it’s easier to have the file be the correct add-on name.
  3. This process creates an add-on that consists of tables, fields, table occurrences, scripts, custom functions, layouts, custom menus, and objects. This process ignores security related features (accounts, privilege sets, etc). This process will also include any sample data in the file.
  4. Once installed by the developer, the add-on is available to everyone using the app.
  5. Each time you generate an add-on from a FileMaker file, you should first go into the AddonModules Folder and delete the previous version. While this add-on process will probably be okay writing over the existing file, we haven’t tested this to confirm. So deleting it is the safest option.
  6. If you do want to change the name of the add-on, you have to do so in the AddonModules folder. Below describes how you can change the name and add other details about the add-on.
  7. There’s a difference between ‘installing’ and add-on and applying the add-on to your layout. The former action, you only do one time. You install the add-on, which includes adding all the schema, scripts, layouts, etc. to the target FileMaker file. Once installed you can apply the add-on many times to layouts in your file.

Making an Add-On

Here’s how you create an add-on to be installed and used in a FileMaker file. This process will create  the entire package of your add-on; anything in the file you’re using to create will be included except for the items described above and the ‘special layout’.

A Special Layout (or many special layouts)

The first thing you do is create a special layout (or many special layouts if you wish to support localizations of other languages). This layout is the place you’ll create the layout object payload–the group of objects that will be dragged onto a layout in your file. This layout will NOT be packaged as part of the add-on. It is only a place to create the payload.

This heatmap add-on consists of a group of objects (highlighted in the Objects panel on the left). That group consists of the web viewer, a button bar (on the left), and a single button (on the right). Additional objects are on the layout. They are NOT part of the add-on.

You can have items on this layout that are used for your development but will not be part of the add-on. See the “Object Groups” section below for further details.

In your new FileMaker file, create a layout using a table occurrence that makes sense for your add-on. This underlying table will be packaged as part of the add-on, and your add-on, if using fields from that layout, will be bound to the table occurrence. If you do not plan on using this table occurrence for anything (storage of data or relationships) you can delete the table occurrence, leaving this layout with no context.

 It can be a utility table that has no real connection to the add-on. Or this layout can be integral to your add-on, as it contains fields used in the add-on.

Give the layout the name of __FMAddonTemplateDirectives_ and add a ISO 639.1 language code to the end. “en”, for example. So the layout is named

__FMAddonTemplateDirectives_en

!! Make sure there are two underscores at the beginning.

The file in which you’re creating the add-ons can have multiple ‘special’ layouts, each with a different language code suffix in the name. The add-on process will create add-ons for each localization you’ve defined in the layout names. See the Localization section below.

Layout Objects

Most add-ons will contain layout objects. The collective set is called, for this document “Layout Object Payload” (this name is only for this blog post; you do not need to name the group).

Create Objects

On this layout, create your objects. These can be fields of the underlying table, or buttons with scripts attached, or anything else that can be on the layout.

Place the objects where you’d like, consider their anchoring as well. And style them as such.

Theme and Styles Considerations

The style of the objects should be considered. Whatever style each of the objects contains will be part of the add-on package. Any discrepancies between these objects’ styles and the file in which the add-on will be placed will be noted as local styling on the object. 

Group the Objects

Once you have all the objects on the layout and in the positions you want them, group them together. Use only one group on the layout. The add-on process will include any objects in the group on the layout. This means you can have other buttons on the layout that are part of your build process (see below). Anything outside the one group will NOT be part of the add-on.

Add-on Names

It is possible to for your objects to have names. Further, you can make each add-on object have unique names in the event you want two instances of the same add-on included on a layout. 

For example, if you create a charting widget with a web viewer, you can use this widget multiple times on the same layout, and, with the unique object name, target a specific instance. 

See the “Add-On Names” section below to understand how to make unique names for your add-ons.

Layouts, Scripts and Custom Functions

An add-on can contain additional layouts that work with the add-on to provide the full functionality. For example, an add-on can have a layout as a card window to display the details of the clicked-on card or row of the Kanban board.

Any layouts, scripts and script folders, and custom functions you create in this file will be part of the add-on package. They will install in their proper place. These add-on parts are used to complete the add-on’s functionality. For example, a script attached to a button that is part of the add-on can open a card window (one of the layouts you created).

Some notes about the layouts:

  1. If you have a layout that contains a custom menu and that menu is set as the default for the layout, that custom menu will get packaged up, but the custom menu will NOT be the default.
  2. Remember: you can have any number of layouts as part of the package. The only layout that will not be bundled are the __FMAddonTemplateDirectives_ layouts.
  3. Upon this special layout you can place additional buttons and objects as you wish. If they are not part of the main group they will NOT be included in the package. Remember, however, any buttons with scripts attached that are meant for ‘developer only’ will still be included in the package; there’s no way at present to exclude scripts from the package.

Including Data

An add-on is a package everything in your ‘add-on-creation’ file, and that includes tables. The add-on can also include sample data inside any additional tables you’ve included. This is useful, along with the layouts you’ve included in the add-on package, to show how the add-on works once installed. We recommend adding Sample data in a table that is clearly marked “SAMPLE”.

Packaging Up the Add-On

Once you have the proper tables, scripts, custom functions, names and groups set up, run a script that performs the step “Save a Copy as Add-on Package”. See the attached file as an example. We’re using a separate file to run this script step so this script does NOT become part of the add-on (It will if the script is in the add-on file).

The options of this step include the Window Name and Replace UUIDs.

Window Name:

  • pass in the window name of this window.

Replace UUIDs: 

  • This option will generate a new UUID for all the objects of the add-on. This is vital if you use the same file to create different add-ons, such as a template file. We’ll explain later in another post.
  • You do not need to replace UUIDs if you use a new FileMaker file for every add-on.

Running this step will create the add-on. It will bring over all valid parts of this file into the package and place it into a folder in the AddonModules folder, which will open up. Any localized versions you’ve created (any layouts with the proper name and a localization code) will be part of the package.

Using the Add-On

Once installed into this folder location, quit FileMaker and restart the app. When you go to install an add-on (layout mode > left panel > “Add-on” tab–the add-on should be available for your use. As a developer you can then install the add-on one time or MANY times in the app (see below for a discussion on ‘multiple instances’ of the add-on). This will install all the parts of the add-on: the scripts, the tables and table occurrences (if any), the layouts (other than the ‘special’ layout), themes, custom functions, etc. The add-on will then be ready for all users of the app.

Naming Add-On Instances

Sometimes you want to have more than one instance of the same add-on on a layout. That’s possible, for sure. You can set up your add-on during your creation process to get a unique identifier.

To ensure objects have unique names, name the object. Include the string [<^FMXML_AddonInstanceUUID>] wherever you like in the name. For example, for a kanban widget, you might name it: Kanban+_[<^FMXML_AddonInstanceUUID>]. Use this string in any other parts of your add-on, including field calculations, script parameters on buttons, etc.

The add-on process will take this string: [<^FMXML_AddonInstanceUUID>] and replace it with a UUID during the drag-drop action. If you install “Twillio Integration” add-on onto your app three times, each add-on instance will get a different UUID. 

As an example: in our Simple Chart FileMaker add-on, the web viewer calculation contains this string as well as the name of the web viewer object. We also use this in parameters on buttons included in the add-on. During the install process, this string gets replaced with a UUID. So even though there’s one set of scripts to run the add-on, each script knows the add-on it should interact with.

The add-on drag/drop process (from the add-on tab to the layout) will update ALL the instances of this string in all parts of the add-on. You can use this feature to make sure that a button as part of the add-on will work with the add-on it is meant to work with.

In the chart widget example above, each add-on has a button with this string as the parameter. Each of the three instances will have a different UUID in the button’s script parameter. So each button will work with only its add-on.

Adding Info to the FileMaker Add-on Module

The add-on package can include additional information about the add-on. For each language you choose to support, you can add the following information:

TitleThis is the name of the add-on. Here’s where you can update the name and this name will show up in the install dialog of the Addon Tab.
DescriptionYou can include a description here to give users information about what to expect in its functionality.
CategoryA defined category. This is how add-ons will be grouped in the install dialog.
FeaturesInclude an array of features, one feature per array-element.
OptimizedInclude information about this add-on’s optimization with different devices. (I would also include whether the add-on works on MacOS, Windows, and WebDirect if you’re using a web-viewer widget add-on.

Additionally, you can include an icon for your addon. Replace the icon.png files in the add-on module’s folder


Onward, and To Be Continued

Give FileMaker add-ons a try. Try to make one. Start simple. The road will be bumpy, but we’ve got yah. Reach out at support@geistinteractive.com for quick answers to your questions, or post in the Claris Community.

There’s a lot more to discuss about the FileMaker add-ons. We’ll make an effort to get more blog posts out giving out all the other details we’ve come to learn in this process. We need to explain about localization, about FileMaker language versions and add-on localizations, etc. We also need to explain how to create an add-on with related table occurrences. That’s a whole other yarn ball to unwind. So stay tuned to this blog for more on FileMaker 19 add-ons.