FileMaker 13 shipped with a new function called GetContainerAttribute(). The function is ostensibly about container fields and their contents. It was designed to let you query the metadata that is often stored along with images; things like geotags, dimensions etc. One the “attributes” that you can get from an image is its MD5 hash. And that’s where things get interesting.
All our videos are HD. Please enjoy in full screen. 🙂
The FileMaker WebViewer is a powerful JavaScript Runtime engine. If you know how to exchange data between the WebViewer and FileMaker you can do all sorts of cool things. In this video we look at a new ModularFileMaker Module I just released, called “Waterwark”. It uses HTML5 and Javascript to get FileMaker’s WebViewer to “watermark” photos for us.
Watermark uses the HTML5 canvas element to place a “watermark” on an another image in a given location, and at a given opacity. Both the photo and the watermark can come from FileMaker container fields. You can control, the opacity, position and offset from within FileMaker as well. You don’t need to know anything about HTML5 or JavaScript to use this module.
GoDraw, our drawing add-on and GoSign, our signature capture add-on, both make use of HTML5 , the Canvas element and Javascript to do their magic. You may want to check them out to see what else you can do with the FileMaker Webviewer.
We calculate a web page to display in the FileMaker WebViewer control. That web page contains all of the code needed to produce the final watermarked image. We then display that web page using a data url. The web page then calls a FileMaker script using the fmp:// url protocol. The script gets the Base64 encoded image as a script parameter.
The file is hosted and available for download at ModularFileMaker.org
Last week we published a video on Syncing FileMaker with Transactions. We used our transactional Filemaker sync framework, GoZync for the demonstration. Although GoZync’s transaction safe sync may be my favorite feature, it is not the only cool thing about GoZync. In this video, We take a look at three of my favorite GoZync features; filtering, check in/check out, and file delivery. Here is some of what we cover in the video.
Many times you don’t want to sync all the records in your main solution down to your iPads. There are too many reasons why this is a good idea to cover in this post, but they often come down to speed, focus, and security. You just don’t want all those records clogging up your users experience, and being left around on somebody’s iPad. So how do teach GoZync what records you want to sync? Simple, you just use FileMaker finds.
GoZync syncs found sets. It doesn’t care how the found set was created. You are free to use any script steps you want create what ever found set you want. The GoZync scripts that make up the sync engine, we called it “zengine”, have hooks in place where you can write the scripts to produce your found sets for each Table you want to sync.
GoZync also has another hook in place that lets you add on to the sync and extend it, all the while staying wrapped within the transaction. These “hooks” are really just scripts that are triggered to run at certain points in the sync life cycle. This hook is fired when you have access to both the server and mobile version of the record. We call this being in the “center of the butterfly”. From there you can set fields on either side of the synced record.
One of the things you can build being in the center of the butterfly, is a “Check in / Check out” sync. When the iPads pull the records down, they can simultaneously and within the same transaction, mark the server records as “Checked Out”. Now you can base validation and business logic on the Checked Out state of a record. Maybe it can’t be edited on the server as long as it is “Checked Out”. Its up to you. You can do the reverse on the Push. You can mark records as “Checked In” if they are marked “done” for example.
GoZync has an automated way to update iPads and iPhones with new copies of the files. New version are uploaded to the server. Users in the field can update their copies of the app in place, with a push of a button. The process completely avoids all the hassle and inconvenience of using email or iTunes to handle file delivery.
GoZync doesn’t require any plugins or server applications. It’s just FileMaker. GoZync embraces FileMaker ‘s methods for doing things like filtering with finds, and custom data handling using set fields. We think this is important. After all, GoZync is a FileMaker Sync Framework for FileMaker developers!
This is part 3 of a video series on FileMaker Transactions. It might be helpful to watch part 1 and part 2 first. But it’s not required. In this video we took a look at why transactions are important to syncing FileMaker and FileMaker Go. We use GoZync, our fully transactional sync framework, to demonstrate why transactions are so important to sync.
There are two key data transfer problems that you must overcome if you expect to be able to reliably sync data. Since both of them involve updating more than one record at a time, they are best solved with transactions.
The first problem is subtle, but important. At the end of a sync both sides , Server and Client, should agree on what just happened. By wrapping the transfer of records inside a single transaction, GoZync ensures that when a commit is successful both sides know it. It also means that when a transfer fails both side know that as well. There is no ambiguity as to what happened
The second one is maybe more obvious. It has to do with how entities that are made up of more than one record are handled. The example we use in this movie are Work Orders. WorkOrders are a single thing or entity, made up a WorkOrder record and one or more related WorkOrderItem records. We show how GoZync uses transactions to ensure that changes made to both WorkOrders and WorkOrder Items are bundled together into a single transaction and transferred up to the Server.
In the video we show how using a non transactional process like import to sync your records can leave your data in an unknown state. Some of the data may be wrong and it can be very difficult to tell exactly what’s wrong. We then show how using GoZync protects against this problem.
Download the example files!
This video is part 2 of a series on FileMaker Transactions. Part 1, titled “Fixing Slow FileMaker Reports” demonstrated one of the many reasons why transactions are an important part of building multi-user FileMaker apps. In this video, we break down the simple FileMaker Transaction that we briefly see in part 1. The video continues with a brief introduction to the low level FileMaker features that are used to build transactions safe scripts.
This is the demo file used for this video
Video Series
This video is part 1 in a series on FileMaker Transactions and why you should use them. In this video, we look at a slow FileMaker Report. The report is slow because it is based on unstored calculations. We look at a way to speed up the report, by storing data closer to where the calculation needs to occur. This lets us create our report using less unstored calculations. The result is a report that is much faster.
However, this opens our solution up to database integrity problems because no we have the same data stored in many places. In theory this is a bad practice. But in the real world of multi-user FileMaker applications running over the internet, it turns out to be something you will need to do.
We solve this problem by employing FileMaker Transactions to make sure that we can reliably keep the de-normalized data in sync.
Part 2. is now available. Simple FileMaker Transactions
This is the demo file used for this video
BaseElements is very powerful free plugin from Goya . Among it’s dozens of useful features is the ability to create FileMaker code in the form of ClipBoard objects and place them on the clipboard so you can paste them into your solution. We used this to add a hidden feature to our GoSign Configurator to make integrations even easier.
Tim Anderson reported an awesome bug with HyperList version 2.0. I wanted to jump right in there and start fixing but the main HyperList script is a bit complicated. So you need to be careful. One of the ways I try to make sure that I don’t break existing codes, is to use FileMaker Unit Testing. I also use unit tests to make sure that I have actually fixed the bug. In this video, I take a look at solving Tim’s bug using FileMaker Unit Testing. I wrote about this a while back, but I thought this would be a good opportunity to bring up the subject again.
The FileMaker Separation Model has been around for a long time. It started way back in the pre FileMaker 7 days. It’s not right for every project, and sometimes you can go too far, (see update below) but it sure can help with large complex solutions. I am not going to go into all the reason why. That has been done elsewhere. But what if you started or inherited a single file solution and now you want to use the Separation Model? Can you do it?The answer is yes and in this video we show you how to get started.
The main reason this works is that FileMaker does everything through the Relationship Graph. In no case, ever, is the data accessed directly from the underlying base tables. It always goes through the Table Occurrences on the relationship graph. Therefor if you change the Base Table that a Table Occurrence is connected to you change how what Base Table the FileMaker code references.
You can use this to move the Base Tables into another file and then reconnect the code in the original file to the new tables in the new file. Sound crazy? It’s not. It works!
Update!… Kevin Frank’s four part series on Radical Separation is well worth read. It’s an excellent exercise. My comment above about going too far shouldn’t be seen as a dig. Kevin’s site filemakerhacks.com is an excellent resource for all things FileMaker. I just don’t think that going to that extreme length pays off in the long run.
Daniel Wood suggested a rather interesting idea on how to make HyperList and MasterDetail even faster. In short he suggested using FileMaker’s built in record ID instead of the primary key. Its really rather brilliant and turns out to work quite well. You can read his full explanation over at Modular FileMaker. Its in the comments for HyperList.
I thought I would give the idea a try with a very large record set to see if it speed things up. Well it did. Here is the video to prove it. Enjoy