KC Embrey has written a custom action to turn the “new event” button in DayBack into a calendar selector. This lets you make new events even faster and is the basis for creating event templates.

Here’s a short video of this mod in action:

KC wrote the original version back in May but just updated it to work in DayBack for FileMaker 19, since FileMaker’s web viewer blocks the right-click listener from firing. In FileMaker, you’ll activate this feature with a key combo like shift-s.

Find details and code you can paste into your DayBack here: make your own calendar selector.

With the move to replace Internet Explorer with Edge as the web viewer backend in FileMaker 19.3, the new default security settings make FMP URLs require more user interaction. You’ll be prompted much to authorize your web viewer to run FileMaker scripts once a session or as often as every time.

(If you’re new to these changes, our blog post on FileMaker 19.3 Web Viewers explains the issue and changes required in DayBack Classic.)

Thanks to Christian at Monkeybread Software for providing the correct registry key, we now have a way to tell the web viewer that we don’t need to be prompted every time we use an FMP URL link in our file. We’ve modified Christian’s instructions a bit to also include the version-specific fmp19 URL that is used in DayBack Classic. We’ve also provided a one-click registry patch file if you’d like, so you don’t have to modify your registry manually.

Here’s a link to download the patch file. To install it, open the FM193FMPFix.reg file that’s inside the compressed zip folder and acknowledge that you want it to be installed on your machine. Then re-open FileMaker and you should no longer be prompted when using FMP URL links from web viewers.

If you’d rather add the key manually in your registry:

1. Open up Registry Editor on your machine.

2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft

3. Select the “Edge” key, or create a new one if it doesn’t exist

4. Create a new “WebView2” key, or select it if it already exists.

5. Create a new string value named “AutoLaunchProtocolsFromOrigins” with the following value:

This is how it should look:

6. Exit Registry Editor and re-open FileMaker and you should no longer be prompted when using FMP URLs from web viewers.

Thanks again to Christian at Monkeybread for the help with this one!

The new 19.3 update brings some significant enhancements but also includes a few breaking changes in the FileMaker 19.3 web viewers on Windows clients.

For example, DayBack Classic will not work in 19.3 on Windows until you make a couple of changes to the file (instructions follow). Folks using web viewer apps like this will want to update those files before moving to FileMaker 19.3. Other apps like ProMaps and FMChat will see only minor changes and some, like the new DayBack for FileMaker 19, are largely unaffected.

Here’s a great summary of all the cool features in FileMaker 19.3.1: what’s new in the latest release or check out the detailed release notes.

In this article:

Breaking Changes: FileMaker 19.3 Web Viewers on Windows

FileMaker 19.3 web viewers now use the Microsoft Edge (Chromium) engine instead of the Internet Explorer engine to render web content on Windows clients. (That’s why these changes don’t affect Mac clients or folks who only have a Windows Server.) This is an excellent change overall and a big improvement over Internet Explorer.

However, it comes with a few behavior changes that can break some web viewer apps. Here are the breaking changes we’ve been able to identify so far:

  • All fmp:// calls on Windows now show a dialog asking for permission to allow the site to open FileMaker Pro.
    • When using a data-URL based web viewer, the permission dialog will appear every time the web viewer loads. Permission is for “localfm.assets.”
    • When referencing external files in the web viewer, the permission dialog is accompanied by an option to “always allow.” If referencing local files, permission is for “file://.” Otherwise, it will be for the URL referenced.
    • If you’re running into this in your own files, you can tweak the registry to grant access without a prompt.
  • Web viewers in Windows clear all settings associated with the site when their FileMaker file closes. This includes local storage, cookies, and selections to “always allow” the site to open FileMaker (described above). Even if FileMaker is still running, it won’t retain those saved settings once the file is closed. It appears these settings are scoped to the file’s session.

The upshot of these two changes is that your users may be asked to OK each time a web viewer wants to run a FileMaker script. In some cases, users may not even see the dialog asking for permission, and it may appear that the web viewer has hung up. And apps that use local storage or cookies to store the user’s state or tokens connecting to APIs, won’t be able to retain those facts after the FileMaker file is closed.

  • New browser security rules in Windows prevent an fmp:// URL from being called when not initiated from a user action like a “click.” There seems to be an exception for this when the web viewer’s layout loads. The result of this behavior is fmp:// URLs don’t need to be executed from a click action if the web viewer is being set when rendering the layout. It’s not exactly clear what “rendering the layout” consists of, as URLs can execute when setting the web viewer from a script trigger or the web viewer content being loaded directly in the object itself.

This means that while web viewers can still run FileMaker scripts using fmp:// URLs when they are associated with links and buttons, web viewers can no longer run FileMaker scripts in most JavaScript callbacks. DayBack Classic uses callbacks to limit the number of times the whole web viewer needs to refresh–helping keep users focussed without “unscrolling” them, and making DayBack Classic feel more like a native part of FileMaker.

Read Full Article →

This update is required for Windows users who have upgraded to FileMaker Pro 19.3 Client and are using DayBack Classic. These steps are not required for deployments using all Mac clients. (For more on the breaking changes in 19.3 web viewers and why these updates are required, check out our blog post here: FileMaker 19.3 Web Viewers on Windows.)

1. Download the DayBack Updater File

Here’s the link: DayBack Update 19.3 Windows.zip

DayBack Classic Updater

DayBack Updater File for FileMaker 19.3 Windows

If you apply the registry fix outlined here, you can go ahead and skip steps 2 and 3.1. Just download the file and go straight to step 3.2. However, completing all these steps will ensure that DayBack Classic works for any windows computer that opens it, not just those with corrected registries.

2. Copy & Paste Two New Scripts From The Updater File

Copy these two scripts from the updater file and paste them into your file. They won’t require any modification after pasting unless you’ve renamed the referenced scripts or layouts (unlikely). But it’s worth reading these scripts after they’re pasted into your file to make sure no references are <missing>: both scripts are very short.

Read Full Article →

One of our most requested features is now live in DayBack for FileMaker 19. Now breakout your schedule by calendar, by project, or by any field. This new option in DayBack’s horizon view means that any field in any of your calendars can become a swimlane.

FileMaker Gantt Chart

And this means you can now chart your schedule by any field. Learn more and see a video of this in action at our dayback.com blog: Breakout By Anything.

Upgrade Incentives

Breakout is available in the new DayBack for FileMaker 19. Upgrade discounts and instructions are available for folks still using DayBack Classic: upgrading to the new DayBack.


Check Out DayBack for FileMaker 19

FileMaker introduced its JSON functions in version 16. They’ve changed how many developers work, both as a protocol for handling data interchange within FileMaker and working with external APIs. The JSON functions are for working with text, but what if we run into a situation where we need to work with actual JSON files? Does FileMaker provide the tools to read and write .json files as well as JSON text?

Looking for our article and example file on the JSON Parsing Function? Here it is: FileMaker JSON Functons.

FileMaker JSON: Reading Files

JSON files are really utf-8 text files, and we have a few different ways of handling them in FileMaker.

The Insert From URL script step can be used to insert .json files that are local to the system or downloaded from an external site or API. The way these files are inserted depends on the target that’s specified in the script step. For example, if a variable or text field is specified as the target, then Insert From URL will simply read the .json file and insert it as text. As text, we can then use the JSONGetElement function to parse the specific values.

FileMaker JSON Script

Sample script For inserting JSON as text

If a container field is specified as the target in the Insert From URL step, then the .json file is inserted into the container as an actual JSON file.

FileMaker JSON Container Field

JSON file inserted into a container as .json file

Since .json files are actually utf-8 encoded text files, we can read the text right from the container using the TextDecode function and specifying utf-8 as the encoding. However, it’s also possible these .json files are getting into the container field using a method that’s not Insert From URL, and the option of specifying the target is not available. Hence, the TextDecode function is useful in that scenario as well. Read Full Article →

Over the past year, we’ve been building some web apps in React that talk to our customers’ FileMaker servers and to Google’s Cloud Firestore database. As part of that, we’ve begun working with Google’s flavor of FaaS (Function as a Service), Firebase Cloud Functions. Cloud Functions, along with AWS Lamba and Microsoft’s Azure Functions, are part of a growing trend towards serverless architecture. The commonly cited advantages to utilizing Cloud Functions over server-based functions are typically:

  • Zero maintenance: No servers to spin up, no infrastructure to deploy
  • Scalable: Google will handle scaling up automatically
  • Pay as you go: You will be billed only when the function runs, rather than having to maintain a server at all times

In addition, you’ll often hear that Cloud Functions have the advantage of being “event-driven,” meaning they can subscribe to events across a suite of cloud services and trigger based on those changes. This is true, but it’s not unique to Cloud Functions. One web app we’re building here, Datapage, relies on server-based, event-triggered functions to send updates to a FileMaker server based on changes in Firestore, and those functions are working just fine.

If these were the only advantages of Cloud Functions, there isn’t much of a case for us to use them. We already operate and maintain a server for Datapage, and we aren’t receiving so many peak requests (yet) that we’d be in danger of overwhelming that server. So why have we begun a foray into FaaS? There are subtle, less discussed advantages to Cloud Functions that were central to our decision to give them a try.

Firebase Cloud Functions

Less Configuration

Our first candidate problem for Cloud Functions was making regular backups of our production Cloud Firestore database. Google provides functions to export all of the database’s collections to a Cloud Storage bucket, insuring us against overwriting production data. We could handle this with the Google Cloud SDK and a cron job on our server, but that would require configuring credentials, environment variables, and maintaining the job. Read Full Article →

We’ve updated our example scripts for notifying users that they may be creating a conflict. Earlier versions of the script were for DayBack Classic, and now we’ve added example code for the new DayBack for FileMaker 19. This customization is a great example of intercepting the event-editing script in FileMaker and reverting changes to an event if your script deems it necessary.

Find Conflicts FileMaker 19 Calendar

Watch a video of this in action and download the example code here:

Conflict detection for DayBack Classic

Conflict detection for the new DayBack for FileMaker 19 and higher


“We cut our planning meeting time by 50%. We are now able to spend more time refining our backlog instead of mechanically completing our schedule. We are super excited about this!” – Jeremy Verrillio, Vice President, CIPS

Happy to share this integration of DayBack Calendar with the FileMaker solution Jeremy Verrillio created for Comprehensive Injury Prevention Solutions (CIPS). Our blog post at dayback.com describes the strategies employed, including syncing to Google Calendar to their availability in Calendly is always up to date.

FileMaker Calendar Sync

Really proud of the work Jason, Becca, and Ann put into creating such an elegant solution.

Case Study & Video at dayback.com/blog

If your web viewer code calls the FileMaker.PerformScript function when loading, it’s possible that it hasn’t been injected into the web viewer yet, and your code will fail with a breaking error. How can we harden our opening routine to ensure this breaking error doesn’t occur and provide the best experience for the user?

Part 3 of 3 of our series on Web Viewer Tips for FileMaker 19.

In a previous post on Web Viewer Tips we discussed how the new version of DayBack uses a familiar JavaScript and API pattern and the benefits of doing this. In this post, we’ll suggest bringing another common JS pattern into your app: try-catch.

FileMaker 19 Web Viewer Calendar

DayBack gets FileMaker data (Events and To-Dos) as part of its loading routine.

“Can’t Find Variable: FileMaker”

The web viewer will initiate making calls to the FileMaker file via the FileMaker.PerformScript function as the web viewer loads, but since FileMaker is also injecting the FileMaker.PerformScript function into the web viewer as it loads, it’s possible that the function hasn’t been injected before your code calls it. This is part of the asynchronous nature of JavaScript, sometimes the FileMaker.PerformScript function is there in time, and sometimes it isn’t. When it isn’t there, the error “Can’t find variable: FileMaker” is thrown. This is a breaking error, and your JavaScript will stop executing on the offending line.

In most situations, we can trap for this kind of error by testing for it in a simple If statement, something like:

However, this does not help and you’ll still get the “Can’t find variable: FileMaker” error even when referenced in the if statement and the code breaks.

Using Try-Catch Blocks

Using Try-Catch blocks is a more robust way of trapping for errors and exceptions in JavaScript. All code run within the Try block will complete even if there is a potentially fatal error. Instead of the error being reported at the browser level, it will be sent to the Catch block as its argument. Here’s an example where the alert function is misspelled.

If the “alret” function is called outside of the try block, then this error would break our code and halt its execution at the line. By wrapping it in the try block, the code will continue safely and pass the message to the console log.

Since we know the FileMaker.PerformScript function will eventually be injected into the web viewer, we’re going to use the try-catch blocks to simply retry the routine a few times so that the injection can catch up with our code. This is the function we came up with, and even though it’s only on web viewer load that we’re worried about the failure, for consistency’s sake, we use it for all our calls to the FileMaker file.

As you can see, the function will try to call FileMaker.PerformScript again up to 5 times. We don’t want to get stuck in an infinite loop, so providing a maximum number of retries is certainly a best practice, although I’ve never seen more than 1 retry be required for the FileMaker.PerformScript to be there and for the try block run without passing the error to the catch block. At the worst, users may experience a half-second delay during the loading routine instead of simply failing and needing to manually reload the web viewer.


The asynchronous nature of JavaScript can create timing issues. Although this error may seem particular to FileMaker and its web viewer, similar issues have existed for web developers for years:  so have the solutions they’ve come up with to handle them. JavaScript may feel new to many of us in the FileMaker world, but we can take comfort that there’s a wealth of experience out there that we can adapt to our solutions. If you encounter similar JavaScript issues with your web viewer apps, even though the exact terminology may be different from what we’re now doing in FileMaker, someone has likely solved the issue. Some googling and searching through Stack Overflow will likely provide the solution.

DayBack Calendar
DayBack's 30-day trial is unlocked so you can customize it and integrate it with your files.
Download DayBack and we'll send you a couple short emails with tips on how to modify it and use some of the coolest features.
Thank you! Please download: DayBack Calendar
Need More?
SeedCode tips & example files in your inbox
Need More?
SeedCode tips & example files in your inbox
Want More?
Be the first to see articles and tips like these
Download TimeZync and we'll send you a couple short emails with tips syncing your FileMaker Go files.
Thank you! Please download: TimeZync
Want More?
Be the first to see articles and tips like these