SeedCode: Next

What's next for SeedCode, FileMaker, Calendars, and the Web

Conflict Detection for FileMaker 19 Calendars

Posted on March 14, 2021 by seedcode · (Add Comment) · Tagged With: Calendar, FileMaker 19, Resource Scheduling

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.

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

Enjoy!

Case Study: Resource Scheduling in FileMaker 19

Posted on March 1, 2021 by seedcode · (Add Comment) · Tagged With: Calendar, FileMaker 19, Resource Scheduling

“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.

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

Case Study & Video at dayback.com/blog

Web Viewer Tips For FileMaker 19 – Hardening the FileMaker.PerformScript Function

Posted on January 30, 2021 by Jason Young · (7 Comments) · Tagged With: FileMaker 19, javascript, WebDirect

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.

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:

If ( FileMaker && FileMaker.PerformScript ) {
   FileMaker.PerformScript ( 'some script' , 'some parameter');
 }

If ( FileMaker && FileMaker.PerformScript ) {

FileMaker.PerformScript ( 'some script' , 'some parameter');

}

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.

try {
   alret(‘Hello World’);
 }
 catch(e) {
   console.log(e.message);
 }

try {

alret(‘Hello World’);

}

catch(e) {

console.log(e.message);

}

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.

function fileMakerCall(payload, retry) {

  //payload argument contains the script name
  var script = payload.script;

  //initialize the retry argument if empty
  retry = retry ? retry : 0;

  //number of times to retry before reloading the page
  //we've only observed the need for one retry befor FileMaker.PerformScript is there
  var numRetries = 5;

  //stringify the JSON payload for fileMaker
  var payloadString = JSON.stringify(payload);

  //begin try-catch
  try{
    FileMaker.PerformScript(script,payloadString);
  }
  catch(e){
    //try has failed re-run on a half second timeout if it hasn't been attempted too many times
    //enable for testing and debugging
    //console.log(e);
    if(retry < numRetries){
      setTimeout(function(){
        fileMakerCall(payload,retry);
      },500);
    }
    else{
      //too many retries, reload the whole page
      //although we've never needed this
      location.reload();
    }
  }

}

function fileMakerCall(payload, retry) {

//payload argument contains the script name

var script = payload.script;

//initialize the retry argument if empty

retry = retry ? retry : 0;

//number of times to retry before reloading the page

//we've only observed the need for one retry befor FileMaker.PerformScript is there

var numRetries = 5;

//stringify the JSON payload for fileMaker

var payloadString = JSON.stringify(payload);

//begin try-catch

try{

FileMaker.PerformScript(script,payloadString);

}

catch(e){

//try has failed re-run on a half second timeout if it hasn't been attempted too many times

//enable for testing and debugging

//console.log(e);

if(retry < numRetries){

setTimeout(function(){

fileMakerCall(payload,retry);

},500);

}

else{

//too many retries, reload the whole page

//although we've never needed this

location.reload();

}

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.

Conclusions

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.

Web Viewer Tips For FileMaker 19 – Hosting Your Web Viewer Add-On

Posted on January 10, 2021 by Jason Young · (2 Comments) · Tagged With: FileMaker 19, javascript, WebDirect

What are the benefits of building a hosted app for the web viewer in FileMaker? And how can we make this approach work in WebDirect where it looks like FileMaker only supports data URLs?

In a previous article, we looked at writing JavaScript for FileMaker 19 that matches a typical JS pattern of making asynchronous calls to a data source and handling the results. One of the important takeaways of writing JavaScript this way is that we can now maintain a single code base for our DayBack Calendar app across all platforms. In this article, we’re going to look at taking this idea a step further. In addition to being able to maintain a single codebase, we can host that codebase on a single server and have the FileMaker web viewer simply reference the server’s URL.

DayBack as a hosted app in FileMaker Pro client

This is a pattern that we’ve become very familiar with: it’s how DayBack works in Salesforce using Salesforce’s Canvas toolkit.

DayBack as a hosted app in Salesforce Lightning

Why Host your FileMaker Web Viewer Add-On?

For DayBack Calendar, which works with different platforms both embedded, like the FileMaker web viewer, and in the browser, hosting offers us a single code base and a single host for us to maintain. If we had to maintain different repositories and servers for the different platforms, that would exponentially more complex with each new calendar source we added–both in terms of architecture and in terms of making decisions on which version gets which features deployed. However, there are other benefits beyond working with multiple platforms that FileMaker developers should consider.

All Users are on the Same Version

Having multiple versions of the same product out in production can make things extra difficult for your support team. Even though there are some scripts and schema to maintain on the FileMaker side, by moving most of the logic into the single JavaScript build we can cut down chasing if an issue a customer is facing is based on a versioning issue or not. New features and bug fixes get deployed simultaneously and while not all features can be used on every platform, the default becomes that all users get the new features.

We worked very hard to develop scripted, in-app updates for the previous version of DayBack, which was not hosted. And even though most updates were installed with a single click, users still didn’t always know to update. This meant that we’d occasionally hear from folks using a version of DayBack that was over a year old, having missed out on a ton of new features and bug fixes. And while our in-app update scripts (alongside tools like Otto) work to minimize the amount of work it takes to get a file back up to date, all these users wished DayBack had just been updated for them. That’s what hosting the file accomplishes.

Connecting to Other Apps

DayBack Calendar can use events from multiple platforms within a FileMaker web viewer, including Google Calendars, Office 365 Calendars, BaseCamp, and Google Sheets. This is difficult to do if the web viewer is based on a data URL since most APIs need to work with a hosted domain for authentication. It would be technically possible to handle this on the FileMaker side with its native cURL functionality, but this would be a lot of FileMaker specific code vs. being able to take advantage of our hosted app’s existing ability to authenticate and work with these APIs. By referencing our hosted app, all these other non-FileMaker sources just work inside FileMaker.

How It Works: Setting Up the Web Viewer

Hosted apps work in FileMaker Pro client’s web viewer without issue. All we need to do to get them to work is to set up our web viewer to reference our server with a few parameters to tell the app in which context it’s being accessed.

https://app.dayback.com/?type=FileMakerJS&fmFileName=DayBack%20Calendar

1	https://app.dayback.com/?type=FileMakerJS&fmFileName=DayBack%20Calendar

However, if we try this in WebDirect, the app will load, but the FileMaker.PerformScript function is not injected into the web viewer code so we have no way of pulling or pushing info between the FileMaker file and the web viewer. In WebDirect the web viewer reference must have the data:text/html prefix in order for the FileMaker.PerformScript function to be injected. In order to get this to work in WebDirect, a data URL is used for the actual page, so the FileMaker.PerformScript function is injected properly, and then include an iFrame that references the hosted app within the data URL. Here’s an example:

data:text/html,
<!doctype html>
<html>
 
<body style="padding:0px;overflow:hidden">
  <iframe id="dbk_iframe" style="margin:0;position:fixed;top:0;bottom:0,right:0;left:0;width:100%;height:100%;overflow:hidden;" frameborder="0" src="https://app.dayback.com"></iframe>
</body>
 
</html>

data:text/html,

<!doctype html>

<html>

</body>

</html>

Using the iFrame in FileMaker 19’s Web Viewer: Sending Data In and Out

At this point, the iFrame is loading DayBack from the server, but the FileMaker.PerformScript function isn’t injected into the iFrame and can only be referenced in the scope of the data URL. iFrames are designed this way intentionally as the parent window and iFrame are typically from other domains and can introduce cross-site attacks. However, modern browsers do provide a way to safely communicate with iFrames via JavaScript if the proper protocols are set up on both pages.

To send a message from an outer page to an iFrame, the JavaScript function the postMessage window method is used. From the parent page, the iFrame element can be identified by its ID and a message sent.

var target = document.getElementById('dbk_iframe');
target.contentWindow.postMessage(  'hello iFrame', 'https://app.dayback.com');

1 2	var target = document.getElementById('dbk_iframe'); target.contentWindow.postMessage( 'hello iFrame', 'https://app.dayback.com');

In the hosted app in the iFrame, an event listener can be added when the page loads to listen for the message and then run the appropriate function, in this case, postToDayBack.

window.addEventListener( 'message',
  function(e){
  var data = e.data;
  postToDayBack(data);
}, false);

window.addEventListener( 'message',

function(e){

var data = e.data;

postToDayBack(data);

}, false);

To send a message from the hosted code in the iFrame to the parent window a similar process is set-up in reverse. Here the domain will be set as a wildcard so we can post the message to a data URL.

window.parent.postMessage( JSON.stringify( payload ), ‘*');

1	window.parent.postMessage( JSON.stringify( payload ), ‘*');

Then a listener is added to the data URL which can then receive the message from the iFrame and use the FileMaker.PerformScript function to relay that to the file.

window.addEventListener('message',function(e){
var data = e.data;
var objectData = JSON.parse(data);
if(objectData.dbk) {
  FileMaker.PerformScript(e.data);
}
},false);

window.addEventListener('message',function(e){

var data = e.data;

var objectData = JSON.parse(data);

if(objectData.dbk) {

FileMaker.PerformScript(e.data);

}

},false);

The reason we test for the dbk property in the message is that the FileMaker script step Perform JavaScript in Web Viewer also uses the postMessage method and this will trigger the listener that’s been we’ve added to the data URL ensuring that we only messages coming from the DayBack iFrame will actually be processed and execute the FileMaker.PerformScript function.

Essentially, the data URL serves as a relay between FileMaker and DayBack since they can’t communicate with each other directly in WebDirect. The idea to do this in FileMaker was mostly inspired by our experience with bringing DayBack to the Salesforce platform as the Canvas toolkit we used there actually provides developers with ready-made tools for doing this kind of communication. So, again we have similar patterns being used across different platforms which helps simplify DayBack’s code significantly. And we have a familiar pattern for getting DayBack working as a hosted app in WebDirect.

Web viewer add-on FileMaker 19 Web Direct

DayBack as a hosted app in FileMaker WebDirect

Conclusions

A hosted app can dramatically reduce the amount of effort required to deploy and maintain code being used by a FileMaker web viewer app. It also provides a centralized way of allowing your app to communicate with other APIs without having to reinvent the wheel with FileMaker scripts. Although there are a few extra steps to making things work in WebDirect, there’s actually not that much additional code needed. Using postMessage and message listeners is also an established JavaScript pattern with tons of examples and best practices available to get you started. In addition to these benefits, if you build your app this way, you’re probably much closer to taking your app beyond the FileMaker platform than you may realize.

Happy hosting!

Refresh DayBack When Events Are Changed By Other Users

Posted on January 2, 2021 by Ann Kiser · (2 Comments) · Tagged With: Calendar, FileMaker 19, Resource Scheduling

Is this your DayBack story? You have users who are primarily using one calendar view for a long time, and another user updates an event. In a busy scheduling environment–like a call center–how does everyone know that something has changed? Normally other users won’t see these changes until they change a filter, change their view, or click the calendar’s refresh button. This can slow folks down or poorly schedule a particular resource or timeslot thanks to out of date information.

Listening for Other Users’ Changes in DayBack for FileMaker

We recently had an opportunity to modify a customer’s DayBack for FileMaker 19 to automatically refresh any modified or deleted events for other users viewing the same data. Imagine – the front desk receives a call from a customer who needs to change an appointment to later in the day. For staff in the back office, this is reflected in DayBack just seconds later with no user interaction required. This is a game-changer for our customer, and perhaps it will be for you as well!

We’ve uploaded a simplified version of what we created that you can paste into your own deployment of DayBack (example file and instructions follow below). Here’s a short video of this customization in action:

How It Works: Execute FileMaker Data API

When a user makes a change to an event, a field on that record captures the host’s current timestamp of when the modification was made. By using the host timestamp, we can ensure that the modification timestamps are consistent, regardless of the time zone any individual user may be in. An on timer script will run for each user, and if it finds that there are events that have been modified, it will update the display of these events.

Read Full Article →

Paginating Firestore Queries with Document Snapshot Cursors and react-redux-firebase

Posted on December 5, 2020 by Eric Ettensohn · (Add Comment) · Tagged With: javascript

We’ve found react-redux-firebase (RRF) to be a big time saver when querying Firestore. Despite the name, the library has robust support for not just Firebase, but Firestore too, pulling in redux-firestore behind the scenes for Firestore operations. The documentation for RRF’s use of redux-firestore’s APIs is scant within the RRF docs themselves, but redux-firestore’s documentation is extensive and can be applied to usage of RRF.

We make use of paginated Firestore queries to infinitely scroll a particularly long list of items. Pagination in Firestore is accomplished through a set of query configuration options that use cursors to determine where to start or end the page of your query. Here’s what redux-firestore’s docs have to say about using a cursor clause to paginate a Firestore query: Read Full Article →

Web Viewer Tips for FileMaker 19 – Writing Asynchronous JavaScript

Posted on November 23, 2020 by Jason Young · (Add Comment) · Tagged With: FileMaker 19, javascript, WebDirect

Should we trust the script execution order in FileMaker? Or should we write web viewer code that doesn’t care?

In FileMaker 19, developers can now use JavaScript in their web viewer apps to call FileMaker scripts directly. And when those FileMaker scripts complete, they can, in turn, call JavaScript in the web viewer to pass results back. While it’s tempting to assume these two things will happen right after each other, it can be more useful to write JavaScript that doesn’t expect FileMaker to hand its results right back.

This article describes writing “asynchronous JavaScript” that’s much more forgiving of different script behaviors in FileMaker and, at the same time, is much more like the JavaScript you’d write when connecting to sources other than FileMaker. As a result, JavaScript developers on your team may find this asynchronous pattern more recognizable than FileMaker-specific methods.

Background: JavaScript in the FileMaker Web Viewer

There’s a lot of excitement over the new JavaScript enhancements introduced in FileMaker 19 that allow bi-directional communication between FileMaker and the web viewer. This means that developers can now write JavaScript apps for FileMaker that follow the typical pattern of sending a request to a data source, receiving a response asynchronously, and then updating the view without having to do any kind of refresh of the web viewer. Experienced JavaScript developers can now approach writing a JavaScript app for FileMaker without learning all the workarounds required to achieve something similar before these enhancements were introduced in version 19.

Technically, it has been possible to do this kind of communication since FileMaker 13, but it involved many complex processes, often using FileMaker’s temp directory. Doing this also relied on the FMPURL protocol, which couldn’t talk to more than one FileMaker version at a time. Worse still, these methods wouldn’t work in Web Direct since neither the temp directory nor the FMPURL protocol is supported there. What you would typically end up with is a JavaScript architecture that was unique to supporting FileMaker. Read Full Article →

Automatic Resource Filtering

Posted on October 18, 2020 by seedcode · (Add Comment) · Tagged With: Calendar, FileMaker 19, javascript, Resource Scheduling

DayBack is designed to be customized, and you can transform both the way it behaves and the way it looks.

KC Embrey’s latest customization adds a new button to automate resource filters. You might need this if you have many resources (people, equipment, or rooms) and want to see a scheduling grid but don’t want to see blank rows for all the resources that don’t have any appointments. Here’s how it works:

That button was added using a few custom actions. Actions are small pieces of JavaScript you can tie to existing behaviors in DayBack, like when the calendar first renders or when you click on an event. In some simple actions, the JavaScript just calls a FileMaker script. In others, like in this example, the actions change the way the calendar behaves.

In DayBack’s documentation, you’ll find lots of example actions you can copy and paste into your DayBack. There are three kinds of action examples:

Button actions – triggered by a button you create
Event actions – that run when you do something to an event: like create, edit, or delete it.
App actions – these run when you take action in the calendar interface, like select a filter.

If you’re new to JavaScript, you may find customizing one of these example actions to be a lot more fun than writing JS from scratch.

Add this to your DayBack

If automatic filtering looks useful, you can add that behavior to your DayBack. (For FileMaker calendars, this requires DayBack for FileMaker 19.) Learn more about custom app actions and download the JavaScript and CSS for this behavior here: Automatic Resource Filtering.

We’re happy to write custom actions for you as part of an implementation package for DayBack; just let us know what you’d like your calendar to do for you.

Improved Charts for Resource Scheduling in FileMaker 19

Posted on September 20, 2020 by seedcode · (Add Comment) · Tagged With: Analytics, Calendar, Resource Scheduling

The latest update to DayBack for FileMaker 19 improves charting options when plotting resources activities against your goals.

On the Pivot-List view, you’ll now find an option to combine all the resource activities into a single curve when charting activity over time. This means it’s now easier to chart a team’s performance, instead of just individual resources’ performance. Here’s what this looks like in action:

In this example, our “team” is any collection of resources–even if they’re not all in the same folder. And “resources” can be anything in your organization that gets overscheduled: trucks, people, or rooms. Some of our most successful customers use resources for business processes or departments.

Find more about resource scheduling in DayBack here (the video towards the top of the page is a great introduction): Resource & Field Service Scheduling.

To learn more about charting and analytics, look here: Introduction to Calendar Analytics.

Remember, once you get a view/chart set up the way you like, you can save and share that using DayBack’s bookmarks. So take your time building a great set of filters that chart the outcomes you’re most interested in, then save that view so you can check in on your progress. Enjoy!

Explore DayBack for FileMaker 19

FileMaker 19 Add-Ons

Posted on June 10, 2020 by seedcode · (7 Comments) · Tagged With: Calendar, FileMaker 19, javascript

We’ve packaged up DayBack Calendar as an add-on: and if you watch the video below, I think you’ll agree that FileMaker 19 add-ons are a game-changer for developers.

What Are FileMaker 19 Add-Ons?

“Add-on” can refer to both the new objects being inserted into your file–a chart widget, for example, could be called an add-on. And “add-on” can refer to the way those objects are added to your file. This new way of installing things is what’s so revolutionary about add-ons. We’ve had chart widgets for years, but installing them could be tricky. The add-on tech introduced in FM19 makes installation much, much simpler.

You can download an app as a .fmp12 file, or download the same file packaged up as an add-on. One, you’ll add to your file the old copy-and-paste way, and one you’ll add to your file using the new add-on process. The end result is the same. However, installing as an add-on is crazy fast. Check this out…

Download & Get Started

Please play with DayBack and see what it feels like to use a new FileMaker 19 add-on: download the DayBack add-on here and then follow along in the video above. When it comes to placing the video in FileMaker’s extensions folder, here’s where it goes:

Mac: HD/Users/YOU/Library/Application Support/FileMaker/Extensions/AddonModules
Windows: %LocalAppData%\FileMaker\Extensions\AddonModules

If you want to continue after that and begin using DayBack with your own records, check out this overview, then follow our instructions here for creating your first calendar.

The add-on package for DayBack is really just a bunch of JSON, not a FileMaker file you can open and use. If you want to download a copy of DayBack you can play with before installing it into your file, download a copy here: DayBack Calendar for FileMaker 19.

Learn How to Make FileMaker 19 Add-Ons

We expect that Claris will eventually publish some documentation to go with the new “Save a Copy as Add-on Package” script step in FileMaker 19. But I doubt they’ll improve on the level of detail Jeremy Brown has provided in his overview. Those are the best instructions currently available: Creating FileMaker Add-Ons.

Add-On Tech is Here, but New Add-Ons Are Not

If FileMaker 19 add-ons are so cool, why hasn’t Claris shipped their own add-ons yet? That’s a good question and probably points to the fact that the add-on tech isn’t completely finished. There are a few rough edges:

You can see things that still need to be polished in the way add-on leave comments behind on the relationship when the add-on is uninstalled
Some aspects of the add-on’s info.json file don’t appear to be respected, or maybe they’re just not in use yet.
You may find your object names prefaced with “com.fmi” if you install add-ons using a system language other than English. For example, you may see layout names like “com.fmi.DayBack Calendar Layout.” That’s not great, but add-ons are easy to uninstall.

Remember that the core add-on tech has been in FileMaker since version 17, where it was used to deliver “add-on tables” like notes and attachments. Those original add-ons are still here in 19, and you can add them to your file just like you add DayBack.

Given all that, should I use add-ons? It seems to us that the newest and most fragile part of the add-on tech is the object you’re supposed to drag on to your layouts, and how that object is uniquely named and referenced in your scripts. DayBack’s add-on doesn’t use that at all. So, providing that you switch your machine to English before installing, we don’t think there will be any problems using DayBack’s add-on.

We expect Claris to include a number of refinements to add-on tech in the next release of FileMaker 19. If you’d like to hold off on using add-ons, you can still install DayBack by hand. Either link DayBack to your file (very quick) or embed it manually (kind of tedious, but not hard). Instructions for both methods are available here.

Coding is Sharing

FileMaker developers have been looking forward to this tech for a long time. Enhancements like this make code more portable and more encapsulated. They are accelerants for the community of 3rd party apps and developers and, in our opinion, are some of the most effective enhancements Claris can make to the platform. Very psyched to see this coming to life: cheers to the product team. And cheers to Todd and Jeremy for publishing their instructions on how to package add-ons!

Topics

Productivity & Making Time

DayBack Calendar: what’s new

JavaScript and AngularJS

FileMaker Go best practices

What works – increasing code quality while staying lean

Collected articles on FileMaker SQL
Subscribe to Our Blog via Email

Enter your email address to subscribe to our blog and learn about new posts by email.

Email Address
About

We wanted a place where we could talk about some of the new things we're working on, post screen shots and code, and get some feedback from customers who want to be part of the development process.

This is where we get to talk about what's coming next from SeedCode.
Search

Headline for site

SeedCode: Next

“Can’t Find Variable: FileMaker”

Using Try-Catch Blocks

Conclusions

Why Host your FileMaker Web Viewer Add-On?

All Users are on the Same Version

Connecting to Other Apps

How It Works: Setting Up the Web Viewer

Using the iFrame in FileMaker 19’s Web Viewer: Sending Data In and Out

Conclusions

Listening for Other Users’ Changes in DayBack for FileMaker

How It Works: Execute FileMaker Data API

Background: JavaScript in the FileMaker Web Viewer

Add this to your DayBack

What Are FileMaker 19 Add-Ons?

Download & Get Started

Learn How to Make FileMaker 19 Add-Ons

Add-On Tech is Here, but New Add-Ons Are Not

Coding is Sharing

Topics

Subscribe to Our Blog via Email

About

Search

jghfgxhcjvb

Popular Pages

Contact Us

What Works

Need Help?

Stay in the loop

Popular Pages

Need Help?

Download