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.
FileMaker Drawing Tool
We are very excited to release GoDraw v2.0 today. GoDraw is a full featured drawing editor that you can easily add to your FileMaker applications. You can give your users the ability to draw on or annotate images, photos, and diagrams. Or you could use it to give your users a FileMaker based whiteboard. In addition to all the new features, GoDraw v2.o runs now runs on Macs, PC, as well as iPads.
Whenever you move FileMaker code from one file to another, you need to do things in the right order. If you follow this checklist everything will work correctly when it is in the new file. Some of this stuff you can copy and paste or import. The rest you will have to manually copy. It’s not fun, but if you need to rebuild a bad file, merge two files together, or just get a code chunk from one file to another, following these steps can get the job done.
- Custom Functions – Copy and Paste or Import
- Tables – Copy and Paste or Import
- Graph – Manual Fix. Make sure relationships and names are set up correctly
- Adjust Fields – Any fields that needed relationships will need to be adjusted. One way to do this is to delete all the fields and re-copy and paste the fields from the old file to the new. That will break relationships, but those might be easier to fix than all of the broken calcs.
- Layouts – Manual. make the layouts with the correct names. Skip content for now. That comes later
- Scripts – Copy and Paste or Import
- Value Lists – Manual
- Themes – Import ( Technically these can go any time before step 9)
- Layout Contents – Copy and Paste content, manually set sizes and parts.
- Layout Based Script Triggers – Manual
- Security ie Accounts and Privilege Sets – Manual
- Custom Menus – Manual
- File Options – Default Passwords and Window Based Script Triggers
Yes, this is a tedious, time-consuming, fragile process. But it is the best we have. In the case of smaller code chunks that have been designed with this in mind, like modularfilemaker.org modules, it can be made to work.
My top feature request for FileMaker 14 is Multiple Parameters for Scripts. It’s a critical part of building complex apps. It’s not yet satisfactorily solved. Compared to other technical issues that FileMaker has taken on like WebDirect, it’s easy. Yet it’s positive impact on the ecosystem would be huge.
FileMaker Inc. has decided that FileMaker is a platform. Platforms live and die based on their ability to create a network effect. Recently I wrote about what the network effect did for WordPress and how FileMaker could learn from it. To sum it up, we need more people, sharing more code. I believe that the biggest impediment to that, is our inability to have a native, standard way to pass more than one parameter to scripts.
What’s my evidence? Years of arguing, wrangling, convincing and cajoling that has gone on in this community over how to do it best. It maybe the number one topic of discussion at modularfilemaker.org. I know it has taken filemakerstandards.org a couple of years to come up with thiers. Imagine what that energy could have spent on, instead of being wasted over something that should be built in.
As an example, this just came up today on Twitter.
3 of ? -to move from what was unofficially a standard to a new standard which is incompatible seems to break down for me and I see (con'd)
— Drew Sanderson (@fmsimplicity) April 7, 2014
4 of? -strong case for the change. @toddgeist is right with the philosophy to think that modules should not use custom functions for (con'd)
— Drew Sanderson (@fmsimplicity) April 7, 2014
@fmsimplicity ( Drew Sanderson ) is hitting the nail right on the head. “This is a pain with out CFs, yet I don’t want to use somebody else’s”. There is nothing wrong with the sentiment. It’s legit.
Technical Solutions to Multiple Parameters
There are lots of good technical solutions. Some that rely on custom functions. Some that do not. Here is a short list.
- FileMakerStandards.org’s Parameters
- Six Fried Rice – Passing Multiple Parameters
- An old one from me – Using List()
There are many more. Incidentally there is a new way that just became reasonable. I will discuss that in another post tomorrow. It’s interesting but I don’t think it solves the problem completely.
Good technical solutions aren’t always what’s best for a community hoping for a network effect. We need solutions that encourage ways of working that allow us to share. Custom Functions do not, as I have argued before. That is the main reason I support FileMakerStandards.org’s Parameters. You can use that standard without custom functions. I wouldn’t quite say it’s the lesser of all evils. But at least it can be made to work without CFs. But it is not as easy as it needs to be.
Watch out for Anti-Patterns
I have shared my opinion on this with all of the project management team at FileMaker Inc. And while they seem to agree that it is important, it never seems to make the list of new features. I think this is because it seems like it is solved well enough for those who care. The custom function solutions do sort of work. But only in the way that all anti-patterns do. They work at first, but eventually lead you down the wrong path. In this case they lead into fragmentation and fragility. These are exactly the kind of problems that must be solved at the platform level.
Pass it On!
We need the ability to pass multiple parameters to scripts to be a core, native feature of FileMaker. We need it ASAP! If you believe this to be true as well, why not help spread the word? Maybe if enough of us ask nicely, we can get some tractions.
As I mentioned earlier this week, FileMaker released FMP 13.0v2 with a fix for the FMP URL protocol. This fix let us get rid having to self host GoSign if you wanted to use it locally, without a server. Today we released a new version of GoSign to accommodate those changes.
There is no new functionality beyond removing the self host warning, when launching in FileMaker 13.0v2 or greater. You don’t need to re-integrate GoSign 3 if you already have it embedded into your solution. This only effects new users trying GoSign.
If you still have GoSign 2 and you are ready to upgrade, please email us. We would be happy to extend a 50% discount to you.
FileMaker 13.0v2 shipped today. One of the things that got fixed was the FileMaker Pro URL protocol. Previously you could only use the URL protocol with FileMaker Go, or with FileMaker Pro hosted files. If you wanted to talk to FileMaker Pro files that were local on your machine you were out of luck. 13.0v2 fixes this (mostly – see limitation below ).
This is big news and has a wide reaching impacts. I’ll have a lot more to say on it soon. But for now, let me just point out that one of the things it does is make integrating the FileMaker WebViewer with FileMaker itself easier. You can now call scripts from web apps, and web pages running in FileMaker WebViewers. We make heavy use of this technique in two of our products, GoSign and GoDraw. Now it will be easier to get these kinds of apps to work.
If your curious about this sort of thing you might want to check out the above mentioned products, or the free ModularFileMaker.org Module, “Watermark” that makes use of this technique as well. There is a unlocked demo file you can tear apart if you want.
There is still a limitation on Windows. FileMaker’s WebViewer is powered by Internet Explorer. Internet Explorer doesn’t allow long URLs. That means you can’t pass back long parameters to scripts. I think the length is about 500 characters, but I’ll have to test it again. [ UPDATE – 4/4/2014] It looks like that limit is 2048 characters.
All our videos are HD. Please enjoy in full screen. 🙂
FileMaker WebViewer and HTML5
FileMaker Webviewer Data URLs
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.
Filtering – Syncing Found Sets
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.
Native FileMaker Sync
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!
FileMaker Inc. just announced the 2014 Developers Conference. I am proud to be presenting again this year. My topic for this year is Modular Design. We will explore the newest tricks and tips for building reusable, sharable, maintainable chunks of FileMaker code. We will dive under the hood of some of the most popular Modular FileMaker Modules (mFMs) that are hosted at ModularFileMaker.org. We will also look at new modular design tools FileMaker 13 offers, in particular, slide panels and popovers provide great containers for building modules.
My session is at 3:45 PM on Tuesday, July 29th. Hope to see you there.
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!
- Part 1 – Fixing Slow FileMaker Reports
- Part 2 – Simple FileMaker Transactions
- Part 3 – Syncing With Transactions