The FileMaker Web Viewer Bridge raises our interaction between FileMaker and JavaScript to the next level. Let’s take a high-level view of this framework.

Working with the web viewer, stage one

In all the work I’ve done so far with JavaScript and FileMaker, I’ve followed one setup. The JavaScript libraries, functions, the CSS, and the HTML are all stored in FileMaker fields. These fields’ contents are calculated together into a single calc field, and this is the field a web viewer uses as its source. For much of the work I’ve done, this method is sufficient. I can display a date picker or a data tables list of actual data from the custom app using this method. It worked.

The Problems

When I want to do more, this method causes a few problems. If I’m using the DataTables JavaScript library to show a portal-looking list of related data and a new record gets added to the related set, I’d have to make sure to add that data to the web viewer’s view. And that requires reloading all the JS libraries into the web viewer. The screen cap below shows the problem.

Likewise, it is a problem when the use case requires a button to make a change to how the web viewer shows its information. If I have a chart, and I want the chart to transform from a bar chart to a line chart, I’d have to update the chart options from “bar” to “line” in the JS function text field (which I could do using Filemaker Scripting).

Both of these possible use cases cause a problem to the experience of using the web viewer. Watch the movie below showing the DataTables JavaScript library integration and see if you spot the problem.

Let’s breakdown what happened

  1. This JavaScript configuration was set up to sort by last name Desc by default. Every time this web viewer loads, those records with last name starting with “Z” shows up at the top.
  2. I sorted by Last Name Ascending.
  3. I added a new related record to the table using a popover, global fields, and a script.
  4. When I pressed “Add Row”, a script ran to grab the related data of this one parent record. The script formatted the data properly and then set the data in the Data field.
  5. This field refresh triggered the web viewer to reload.
  6. When the web viewer reloaded, it took the calculated HTML document and reloaded it into the web viewer, causing the flash and causing the sort state to be reset to its default for this configuration.

Bridging FileMaker and JavaScript

The FileMaker Web Viewer Bridge solves the problems described above. This framework bridges the FileMaker platform and any JS libraries you are using, forming, as most bridges do, a two-way connection. FileMaker can ‘talk’ to the JS loaded into a web viewer, and the web viewer can call back to FileMaker.

Here’s what it looks like.

Did you see it? Let’s breakdown what did and didn’t happen.

  1. I sorted the data using both position and Last Name (yes, that’s built into DataTables).
  2. I used a FileMaker popover, global fields, and a FileMaker script to add a new record.
  3. When the record was added:
    1. The new row immediately appeared
    2. The sort state did not change
    3. The record was added to the rows, there was no flash.

We still loaded the new record into the web viewer, but we did so without resetting the web viewer. That’s the power of the FileMaker Web Viewer Bridge. The popover I used to add the record contained a button that ran a FileMaker script. That FileMaker script sent the new record’s data to the JavaScript library, calling a function in DataTables JS to add a row.

Calling back to FileMaker

Just as we can use FileMaker to call a JavaScript function, the FileMaker Web Viewer Bridge allows a JavaScript function to call a FileMaker script. This could already happen using the fmp protocol, and indeed the Web Viewer Bridge uses the FMP protocol. The complex syntax of the statement is removed.

The Devil’s in the details

We’ll go into detail about how you can use the FileMaker Web Viewer Bridge to accomplish the above tasks for any JS library in future posts and videos. There’s some specific points to cover. We cover the following topics:

  • Setting up the JavaScript to run FileMaker Scripts
  • Setting up the JavaScript to allow FileMaker to call a JS function.
  • Loading all HTML / CSS / JS into the web viewer.
  • Connecting to the FileMaker Web Viewer Bridge
  • Sending data created in FileMaker to a JavaScript function
  • Calling back from JavaScript to FileMaker

There will probably be other topics along the way.

It’s for Everyone

The power of the FileMaker Web Viewer bridge, all of the possibility it opens up, is not beyond your skill as a FileMaker developer and a budding JavaScript developer. Yes, you’ll have to learn some JavaScript, but we’ll cover that together and in minute detail.

Download the sample shown in the screen casts above as well as the original FileMaker Web Viewer Bridge file. Read through the documentation (found there on Github) and stay tuned here to learn more about the FileMaker Web Viewer Bridge.

TODAY  – 10/22/2018  – 6:30 PM Pacfic!

Next Monday ( October 22 ) Geist Interactive will be hosting the San Diego FileMaker User Group at our office in San Diego, if you don’t live in the area and still want to attend, you can join us via Facebook Live on our Facebook page.

We are going to attempt something interesting.  This is not just a webinar, or Go To Meeting. This a multi-camera Live Streamed event. We’ll have a  “director”, who will be able to switch between multiple camera angles and the presenter’s screen to provide the best view of what’s happening at the event. If everything goes well it’ll be like a TV show with a Live Studio Audience.  We’ll also take questions from the online crowd via Facebook Live.

Last Of the West Coast Tour

This is the final leg of our 2018 West Coast Tour, where we have been talking about Power Tools for The FileMaker Workplace Innovation Platform.  Here are some of the topics we have covered in the earlier shows.

  • JavaScript Intro and mini-workshop
  • Karbon – our free Ambitious App Starter.
  • Otto –  Fully automated data migrations
  • LedgerLink – Connect to Quickbooks from FileMaker

Watch the Live Stream

The Live Stream will start at 6:30 PM Pacific Standard Time. October 22nd, 2018. Join us on our Facebook page.

Attend in Person

If you are in the area please come in and be part of our studio audience. We gather for food and drink starting 5:30 PM at our office in San Diego.  The presentations will begin at 6:30 PM

Address

Geist Interactive
1855 1st Ave Suite 103,
San Diego, CA 92101

Integrating JavaScript libraries is becoming an obsession of mine. I spend my half free time searching for new integrations that might work in FileMaker, and the other half implementing those. I look for JS libraries that are accessible and ones that provide functionality that might be used in a custom app. I think that this next one, a FileMaker Audio Player can be very useful. Let’s take a look how to integrate this simple library.

Feel free to download the sample files here.

This video describes how I set this up. It’s shorter, about 35 minutes. As is usual, I make some mistakes along the way.

Key Points

Setting up the FileMaker audio player

Just like the other videos, we set up an HTML table in the normal way. We’ve got fields that will hold each text file: the HTML, the CSS, and the JavaScript files.

It’s common for me to do this since this allows the JavaScript to work offline. All the code needed for the library, in this case the FileMaker Audio Player, to work is in a record in a table. The web viewer can work with the text in each field.

Also, this structure closely resembles an actual web page construction. A web designer will create one file for each CSS or JavaScript library. Then, in the HTML document, she will link those together. We’re doing roughly the same thing here. We’ve got placeholder text in the HTML field. FileMaker’s calculation engine will, in the HTML_Calc field, do the work of placing the code inside the HTML page at runtime. And the web viewer will work.

The placeholder text set up resembles how web designers structure their page.

The placeholder text set up resembles how web designers structure their page.

There’s another way to work with libraries: our Web Viewer Bridge set up. That’s a free tool you can use. We’ll study it in an upcoming blog and video (more likely a few of those).

The Audio

The FileMaker Audio player can play an actual audio file that is stored in a container field. The library plays it in the web viewer. The web viewer, however, needs the audio file in base64 encoded form, so we have to base64 encode the file in another field or on the fly.

In the video I use the old FileMaker function Base64Encode. This works, but it places a return character after so many characters. And those characters mess up the audio file. I should have used the new one: Base64EncodeRFC which accepts a parameter in the form of a number telling the function to not insert any return characters.

Once the audio is encoded, it is placed in the Data field and used in the JS_Function field in a function there.

The possibilities

This library does one thing: it plays audio showing that audio’s wave form in a web viewer. It does have a few possibilities. Here are some of the options you can update:

  • The color of the wave form
  • The color of the progress wave form
  • The color of the current-time indicator
  • The height of the wave form
  • The playback speed

There’s a lot you can do with this.

Additionally, you can add buttons that do more, that control the wave form. In my final example, I added a button to change the playback speed and a slider to adjust the volume. These two are in addition to the standard play/pause.

Use your JavaScript skills

Finally, I put together JavaScript functions to make the user experience better. For example, the button that plays or pauses the audio has text that changes. If the music is not playing, the button says “Play”. When I click on the button and the music begins to play, the button’s text changes to “Pause”.

This type of functionality can only be done by actually using JavaScript to change the text. During DevCon 2018, we spent some time learning pur JavaScript. Though it wasn’t as exciting as the integrations, learning JS is essential to actually using the libraries. I couldn’t change the text from “play” to “pause” without knowing some JavaScript.

Try out the FileMaker Audio Player

Give this one a try. Even if you’ve no immediate use for it, it’s worth the time to practice your integration skills.

The Workplace Innovation Platform we know, called FileMaker, is exactly that: A platform. There’s many components in the platform. As we add those components to support all the clients’ needs in the custom app, we have to take special care about each. One thought to keep in mind is the script step compatibility. We have to make sure each step in each works in the platform in which we intend. So let’s take a look at FileMaker script compatibility.

FileMaker Go, FileMaker Pro Advanced (on macOS and Windows), FileMaker WebDirect, FileMaker Server, and the FileMaker Data API work very similarly. But there are some differences whether or not script steps work. Some steps are not supported in a part of the platform, and some steps are partially supported. It would be mind-boggling to remember which steps work where, so the script workspace gives us a tool to use.

Many of my script steps do not work for the FileMaker Data API component.

At the top right of the script workspace is a button that opens this dropdown. We can use it to examine a current script to see which steps are not compatible with the selected component. You’ll see any incompatible script steps grayed out.

Additionally, we can use this dropdown to examine the script step list to see which steps are compatible.

So the lesson is: when we are writing a script, we should use the FileMaker script compatibility checker to make sure each step will work. We need to design scripts that are the best for each part of the platform. We need to review existing scripts to make sure each step will perform correctly in the chosen components.

Scripting smarter

Scripting compatibility sounds like a lot of work. Either I’ll have to create one script per component to do the same thing, or I’ll have to have a lot of logic inside a script to handle all the possible places a script will be run. But it really isn’t too hard. And if you think about it, what’s worse: more work or incorrectly-performed scripts?

Here are some strategies you can use to ensure you’re scripting smarter: efficiently and effectively.

Get to know the components

Many seasoned developers have an encyclopedic knowledge of the entire platform, and that includes knowing which steps are compatible with a part of the platform. This simply comes with experience. I don’t think it’s that these developers know all the compatible steps for, say, FileMaker server, but they know what FileMaker Server can and cannot do.

For example, we know two ways to run scripts with FileMaker Server: Perform Script on Server or Schedule Scripts. Each of these uses the scripting engine inside Server. It opens an instance the custom app only in memory. No UI is drawn. So we have to consider what this means. There’s no window, so the Move/Resize Window step is useless. That’s why it’s not compatible with server. (if you do use this step on server, nothing bad will happen. We’ll discuss its consequences further down).

Likewise, the script step Get Directory does not work in FileMaker WebDirect. We know this because that component does not have access to a client’s file system. FileMaker developers in the game for a long time know this.

One caveat

FileMaker, Inc. continually updates their platform’s functionality, and thus FileMaker script compatibility changes. Script steps that were not compatible in a part of the platform in the past are now compatible. The script step “Save Records as PDF”, back in the old days of FileMaker 15 and earlier, was not compatible on server. Since FileMaker 16, it has partial support.

Once you know how a component of the platform performs or works, you can more efficiently pick those steps that will work and work around those steps that you need that won’t work (if possible).

Write Component-targeted scripts

This strategy involves writing a script for each component that will be used. If I need a process to run using the FileMaker Data API, I should write a script just for that process and component. Even if that same process is used in FileMaker on Windows, there is a benefit to having two separate scripts that do the same thing (roughly) that are customized to that component’s script compatibility.

My script workspace might have folders for each component:

  • Go
  • API
  • WebDirect

and so forth that hold specific scripts.

To start, I’d build a script that works completely on the most common component used in my custom app. I might start with FileMaker Pro Advanced on macOS. I’d build the script, duplicate it, and adjust it for the Data API as necessary.

In-Script Logic

Another strategy to use when working with FileMaker script compatibility is to use logic in your scripts that skip over incompatible script steps for any component. This involves checking for the component that is running the script, and then, at each step in question, skipping over it or performing a different set of steps that do work for that component. The functions Get(SystemPlatform) and Get(Device) are good candidates for component-checking. There are also custom functions that provide this functionality as well. _IsWin will return 1 if a Windows machine is running the script.

The Consequences

When the FileMaker runs a script, it will skip over any steps incompatible with that component. Sometimes that isn’t a problem. Show Custom Dialog is not compatible on FileMaker Server, and Server will skip that step. That’s okay if the script step was meant to show a success message. If, on the other hand, the step included input fields which are used in the rest of the script, there’s a problem. So you have to consider each incompatible script step and decide if the script will break if the process is incompatible.

What is ‘Partial’?

There are quite a few script steps that have listed “partial” in the supported column. Save Records as PDF is one of those. It is partially supported in FileMaker Go, FileMaker WebDirect, and FileMaker Server & Cloud. It seems odd. Why would a step be partially supported? As with anyone’s enjoyment of brussel sprouts, support seems binary. No one ‘partially’ enjoys the gross-smelling green sphere.

Well it turns out FileMaker can support some parts of some script steps. These steps happen to be ones with many options. The Script Workspace is helpful in showing which parts are supported and which are not.

When we encounter a partially-supported step, we can use FileMaker’s documentation to review the partial stuff. (By the way, did you know you can get to the documentation by right-clicking on a step in the Steps menu and choosing “Help”? That’s cool.) The Partial information is found in the notes.

In this case, Save Records as PDF is supported, but the dialog will not show up when this step is run from FileMaker Server. So it is wise to review the notes for partially-supported steps.

FileMaker Script Compatibility: Write scripts with all the tools

FileMaker Script Compatibility is an essential part of every developer’s skill-set. Whether she knows how each of the components works and their functionality limitations or she uses the compatibility checker, it is vital that each script runs successfully and does what it intends to do in every part of the platform.

We need to do better logging in Karbon, both developer logging at design time, and process logging at runtime. This video covers some of the progress we have made towards solidifying our approach to logging.

Why not just use DBTransactions?

It is tempting to use the DBTransactions table as our log, and in fact, it includes many log-like features. However, DBTransactions is really about database transactions, not logging. Logging is really a separate thing, which has many nuances of its own. Conflating the two concerns is probably not wise in the long run.

Logging from within Transaction

The other problem is that you want to log info from within a transaction and make sure that data stays even if the transaction is reverted. So step 1 is to develop a log method for logging within the transaction. That “transaction log” can later be sent of to the main log, which we’ll get to later.

This feature is not yet “done”. More work needs to go into generic logging, and process logging. Stay tuned for that.

Karbon Info

Karbon is our free framework for building complex apps. We share rough updates like this from time to time because people have expressed interest in what we are doing. For more info on Karbon see here.

JavaScript libraries bring additional and deeper functionality to a FileMaker custom app that are not yet available inside the platform. One widget that I’ve used occasionally in the past was a Date Range Picker. This particular integration is pretty simple to set up and to use. It allows us to add a picker to our custom app that is customized to our locale and easily sends the selected dates back to FileMaker. So let’s study how to work with this FileMaker Date Range Picker, just as we’ve done now with DataTables and C3 Charts.

In this post, I’ll summarize the key points of the video and point out the sections of the 45 minute tutorial. Also in this video, we examine a few ways to spread this integration to any part of your custom app. It’s the first time we’ve talked about this specifically, but I’ll bring it up in a future video.

Here’s the file if you want to follow along and build a FileMaker Date Range Picker.

Sections

The video is 45 minutes. I walk through how to set it up, make a few mistakes along the way, but fix those in time. Here’s the breakdown:

  • 00:00–Intro and integration
  • 20:41–The Callback function: Sending the dates to FileMaker
  • 31:30–Setting up Options: changing how the date picker functions.
  • 38:57–Using in FileMaker: strategies for spreading the integration to many parts
  • 44:57–The Finishing Touches: Causing the picker to appear when the window loads

Key Points

Setting up the FileMaker date range picker

Here we go through our normal process of setting up a table to hold all the libraries, the HTML document, and the JavaScript function. We don’t need a data field since this is just a widget. I’m considering a sort of ‘generator‘ to help me create the fields and tables we need so that we don’t have to go through this tedious process every time. (FYI: There is another way that we’ll get into in an upcoming movie that deals with our Web Viewer Bridge Library).

We also set up the layout to be accommodating for us to enter and edit the libraries.

Interesting details

This integration came with a bunch of interesting little points that we may not have addressed before.

  • We built an input text box in the web viewer, and we added a font-awesome icon just to the right of the input box.
  • We used our knowledge of JavaScript to change the code just a little bit. That was fun.
  • The JQuery function $ (it really is a function) applies a date picker method to the input text box.
  • That date picker method: datepicker() is something the author of the library built for us. It is somewhere in the DatePicker library. We don’t have to worry about it. He’s tested it many times. It works very well. It’s like us calling a script from a separate file. We don’t have to understand it, we can just use it.

    A picture of the FIleMaker date range picker.

    There are options galore!

  • There are many options, and we could spend hours configuring this widget to our needs (for fun, not because we have to build each option).
  • What’s cool about the options is that one line of code:  “showdropdowns: true” is all it takes to add a month and year dropdown that updates the calendar to the widget. Or this one: “timePicker: true” draws and adds the time-picker functionality. Wow.
  • the Moment.js library handles date and time formatting for me. I don’t have to do any conversion of the dates when they’re brought into FileMaker. This is a great library I wish I could use more in everyday FileMaker work.

I’m only human

Throughout this video, I made a few mistakes. Here is a rundown of what I did, which happen to be the common errors anyone could make:

  • I forgot a comma in between object properties.
  • I would sometimes forget the closing parenthesis or bracket. This vexed me a few times. I mention in the video that it is best practice to write the opening and closing brackets or parentheses at the same time before filling in the function or options. You are wise to get the hamburger buns before putting in the meat and toppings.
  • Sometimes I put options in the incorrect place. The solution with this comes simply by understanding the structure of the JavaScript.
  • The order in which the libraries loads matters. In this case, the JQuery library needs to be loaded before the DatePicker library. And both of these are required for the actual function to work.
  • The Substitute Function in FileMaker is case-sensitive. “**JQuery**” is not the same as “**jQuery**”. So placeholder text and the text inside the substitute function must be the same.

A picture of my errors

Applying the FileMaker date range picker anywhere

We also briefly touched two ways to allow this to be used anywhere in your custom app. Since we’re dealing with fields in a table, we either have to establish a relationship or load the data into global variables or fields with global storage (global fields). I built this both ways. As FileMaker developers, we can understand the pros and cons of each way, but I’ll bring that up in a future video.

This is a good and simple widget. It is powerful and easy enough to use in any custom app. Give it a try. If nothing else, it’s good practice.

Download the files that I used and see how satisfying it is to build a fully-functional FileMaker date range picker widget. I’ll continue demonstrating integrations from my DevCon 2018 session. And if you haven’t yet, please join our FM/JS Slack channel.

We all want our custom apps to be faster, right? As problem solvers, we design our system and complex processes to happen quickly so that the user can get on with her task. Well one method we have at our fingertips is FileMaker Perform Script on Server. Let’s discuss this script step, its features and things to watch out for. As we study it and use it properly, we’ll use this script step like a boss.

Filemaker Perform Script on Server

This small-seeming script step was introduced in FileMaker 13. Its purpose is to, as it is called, perform a script on the server. Of course this only applies if a file is actually hosted. You can specify a script in the current file or external data source file, run it up on the server, and get back the result. We’ll look at why this was such a game changer below.

Perform Script on Server (P.S.O.S., as FileMaker devs like to call it) works in FileMaker Pro, FileMaker Go, and WebDirect. It is not supported in Runtimes, and it doesn’t make sense in Server schedules–scheduled scripts already perform on the server.

Along with the script name and the parameter, you can specify to “Wait for Completion”. We’ll get into this more later.

The Advantage

Complex tasks take up a lot of computing power and time when run against hosted data on a client machine. As of FileMaker 15, records are cached in the local machine, but FileMaker still might have to fetch new records, process them in some way, and then send the updated records back to the server. That’s a lot. FileMaker Perform Script on Server does the complex tasks right there on the server, where the records are actually sitting. There’s no transfer of data back and forth. Server simply does the work, then updates the client cache with any changed data. The difference in time between the same script running on the client and the server is noticeable.

With great power . . .

As with most things in life, when you’re given a great tool, precautions must be taken and your eyes need to be extra vigilant. Perform Script on Server, too must be handled carefully.

Who is performing the script?

When the PSOS script step is called, it opens the file on the server with the same security as the current user invoking this script step. If I log into the hosted file on my machine as “jbrown” with a privilege set of “HR”, any PSOS script I run will operate with those same security settings. The log in for PSOS is very similar as mine in terms of security, but nowhere is a UI drawn as I would see it on my machine. FileMaker Server can open the file and perform the script with no interface. This login also opens up and runs the onFirstWindowOpen script. If the first-run script sets globals and go to a “dashboard” layout, then PSOS will do the same. Even though it logs in with my username and password, it still is the server running the script. So any functions that return the current time/date, will return Server’s current time and date.

Context is king

FileMaker Server is powerful, but when a PSOS script is called and FMS begins the work, it has no idea where to begin. At the end of the PSOS’s login process, the script is on the onOpen layout, but that’s often not the context in which you want to perform some processing data. So you need to explicitly add a script step in the PSOS script to go to a specific layout. Additionally, it is vital to make sure all globals used in the rest of the script are updated as necessary.

Missing Values

Likewise, any values set in fields with global storage or global variables will be empty. Even if a global field or variable was set in the client file, they do not exist in the PSOS session.

Which records?

Just like the context and global values, the FileMaker Perform Script on Server script doesn’t know which records upon which to work. The script running on the client, the one that called PSOS in the first place may have found some records, but that means nothing to the work done on the server. So in some way, PSOS needs to know which records to find. And you can do this in many ways. Here are just a few:

  • Do the find of records in the PSOS script itself. Let FileMaker Server find the records. But of course, you’ll have to tell the PSOS script which records to find. And that can be done by passing the find criteria in as a parameter of the PSOS script.
  • Do the find in the script performed on the client. Pass the primary keys of the entire found set up to the FileMaker Perform Script on Server script. Include in this script a layout on which is a field. In this field is placed the primary key list. FInally use Go To Related Records to go to the correct context from the starting point of this field.

What edits to make

Once PSOS has the found set, it is vital to tell it what to do with these records, what updates to make.  Again, since the client script probably has that info, the PSOS script step must pass this information up to the server. Along with the find criteria, I’d pass this up to PSOS as a JSON object. We often use fields with global storage as places people can enter find criteria. Those aren’t available in the PSOS, so we have to pass it up. Here’s a sample of what I did while working with my user group colleague.

The first item was the find criteria. The remaining items were used to update the found set of records. Both the find criteria and the update info were generated in the client-run script based on user choices.

Locked Records

Just as a client-run script, if a record is locked, the FileMaker Perform Script on Server script cannot update that record. If we’re in the middle of a loop and the 47th record is locked, it won’t get updated. We have to handle that in some way.

We advocate a transactional approach to handle records that might be locked. If all of them should be processed or none of them, transactions are the way to go.

Errors

PSOS cannot be debugged in the normal sense using the Data Viewer and Script Debugger, so instead we have to find all the errors in our code and eliminate those. But we also have to prepare for unexpected events. To the former, as we work on the script, we can choose to run it on the client instead and debug it using the normal tools. We work through the script and make sure that everything works as expected. We also make sure that the script goes to the right context and finds the right records.

Unexpected events happen, and unexpected events could happen in the PSOS script, and that could cause major issues. So we have to be extra diligent in bailing out of the script whenever an error is encountered that would break the rest of the script processing. Here are a few times you’d want to bail out of the PSOS script when an error occurs

Possible Errors to check

  • There are no records in the found set.
  • The PSOS session fails to go to the correct layout
  • A record fails to update (though you may want to handle this differently. Rather than bailing out of the PSOS script, simply log the record that is uneditable).

The bail out process is pretty simple: After setting Error Capture to be On, get the error of the previous step. If it is not 0, then exit the script with that error code as the exit parameter:

Set Error Capture [On]
…
Perform Find
Set Variable [$json ; JSONSetElement ("" ; "error" ; Get(LastError) ; JSONNumber )]
If $error <> 0
Exit script [ $json]
In the client script, the one that called the PSOS script, use Get(ScriptResult) and see what error took place: JSONGetElement ( $result ; "error").

Wait for it

Finally, the option to Wait for Completion in the FileMaker Perform Script on Server, which is on by default, simply tells the calling script to wait for the PSOS script to finish its work. In most cases, you want this. The script on the server is working, processing a bunch of records. That process needs to finish before the client script can continue. But it is possible to uncheck this option and allow the script to work on its own. There seem to be a smaller number of times when you’d want this, but it is possible.

Perform Script on Server: Use it

FileMaker Perform Script on Server is a powerful tool that offloads complex processes to the server. When used properly and when considered carefully, its use can speed up the processing of data for your users.

 

We are excited to announce that our FileMaker Addon LedgerLink now supports adding and syncing attachments. This feature is included in LedgerLink v3.1.0.

Here’s a rundown of the features:

  • There’s a portal to store any number of attachments.
  • LedgerLink automatically filters to allow Quickbooks Online supported attachments. Those include
    •  PDF
    • JPEG
    • PNG
    • DOC
    • XLSX
    • CSV
    • TIFF
    • GIF
    • XML
  • Once the files are added to LedgerLink, they can be synced to Quickbooks Online just like any other data.
  • LedgerLink includes the ability to add “Existing Files”. These are attachments stored already in LedgerLink. A quick and simple interface allows you to attach enter of these into the invoice record and thus synced.
  • Each attachment can be previewed. This is done by exporting the file and opening it up.

Check out LedgerLink. Download the demo and give it a try.

 

If you want rich interactive charts in your FileMaker app, you are going to need to go beyond the built-in FileMaker charts. Luckily, the FileMaker Workplace Innovation Platform has escape hatches you can use to get just about any job done. In this post and video, I am going to show you how to make FileMaker Interactive Charts with the maybe the most powerful escape hatch in the professional Filemaker developer’s toolkit, JavaScript!

Why Not Just Use the Built-In Charts?

The built-in charts that come with FileMaker out of the box are fine.  They work well and look pretty good. But they are static. There is no animation and they don’t respond to clicks. There isn’t any way to drill down into data sets or otherwise explore the visualizations. Also, data visualization goes way beyond whats provided by the built-in charts.  If we need that extra innovative experience in our apps then we reach for the JS.

FileMaker Interactive Charts

We’ll need some JavaScript and a charting library. We’ll use C3 for this demo. The C3 Charting library is a built on top of D3 the most popular data visualization JavaScript library on the planet. It provides a lot of functionality and a lot of customization possibilities. Take a look at this video to see how to set up the library in your custom app

Oh, and download the files here to follow along.

FileMaker C3Charting

The video is about 45 minutes long. Here’s a breakdown of the sections:

  • 00:00–Setup
  • 17:40–Customization
  • 31:33–Handling Clicks
  • 40:41–Dashboard Possibilities

Some notes

Completely customizable

FileMaker Interactive Charting gives us complete control of the chart. Here’s a partial list of elements we can control:

  • The type of chart
  • Displaying two types of charts in the same graph.
  • The labels and their format
  • The x-axis categories, their display format, and the number of ticks.
  • The y-axis placement (left, right, or both)
  • What happens when you click on or hover over a data point.
  • The colors of each line or bar or pie segment
  • Whether or not grid lines are drawn in the graph

It’s incredible what we can do, and it is fairly easy to set up.

Takes some time

FileMaker C3Charting does take some time to set up, but it gets easier the more times you do it. There’s the data structure and the library files code copying. You have to write in the customization you want and so on. There’s a lot to do, but that’s okay. It is worth the time to get the chart exactly how your client wishes it to be.

FileMaker Interactive Charts

Dashboard possibilities

With a Web Viewer and with this charting library, you can set up a dashboard. More than one chart can be visible, each chart having different properties. With this library, a dashboard is easy to generate.

We will revisit this

FileMaker Interactive Charts requires a lot more discussion, so don’t think we are done with this discussion. In a future video, we’ll explore how to use JSON as the data that drives the chart.

Onward

The C3Charting JavaScript library is great Pro tool to add to our tool box when we need to go out that escape hatch and get the job done.  In this case, we made some awesome FileMaker Interactive Charts. We’ll continue our study of JavaScript that we began at DevCon. Please join us in the SLACK channel, and we’ll talk about these. And stay tuned to our site for more integration videos.

 

 

 

In the DevCon 2018 training session on JavaScript, we took a look how to integrate various JavaScript libraries into FileMaker. We only got through one, and I’m sure I went pretty fast during the remaining minutes to make sure that I at least completed it. I might have lost a few folks. 🙂

But that’s okay. No DevCon Attendee left behind!

The week after DevCon I began to record videos of how to do the work. My plan was and is to work through each integration and walk through how I’d do the work.

So here’s the first one.

DataTables in FileMaker

Here’s the files for you to try out.

TL:DR

This video is long. It’s 53:00. So I broke it up into a few sections. Check out any of the sections in which you’re interested. (But, it’s good to watch the video in whole).

  • Basic Setup: 0:00
  • CSS Styling: 30:38
  • Functionality (adding the row click): 38:20
  • Table Options: 51:02.

Some Thoughts

It’s a fairly speedy process

I’ve done this enough that I can set up an integration in less than 20 minutes. I usually export all the code from a previous project or a practice file, so that makes things go even faster. And with more practice, you will get even faster. One DevCon attendee reported to me that he thinks it would take him 10-15 minutes to do another integration. The set up I’m advocating is simple. It’s fields and tables. That set up works for now.

Styling can take some time

The hardest part of this is styling it. You have to get down into the nitty-gritty of the CSS and adjust individual items. In the above video, I talk about it a bit, but this will require some more study.

The default library is a good start

DataTables comes complete with a full set of functionality. Once you install it into your custom app and load it with data, you can sort by columns, do filter-as-you-type, and adjust the number of records showing. There’s no additional scripting or buttons or tricks; just use what the (very well tested) library provides.

Alt ways

I’m suggesting one method here. But there are others, and we’ll discuss those in the future.

There’s one more method for using DataTables in FileMaker. For all my talking about using JavaScript in FileMaker, I’ve got a config file that will allow you to set up an integration without knowing any of the underlying JavaScript. Check that out here.

Onward

DataTables in FileMaker is one way we can innovate in FileMaker. We can provide a professional set of functionality to our clients. This functionality may not be needed for every list or portal. However, if the client asks that related records are sortable and searchable, we can turn to this library for complete help.

We’ll continue our study of JavaScript. Please join us in the SLACK channel, and we’ll talk about these. And stay tuned to our site for more integration videos.

Download the source, start file and finished file here.