While John Sindelar and I were doing our West Coast FmPug tour we sat down with Matt Navarre to do a podcast. Actually we didn’t sit, we stood, but you get the idea.  We talked about the upcoming release of GoZync, and a bunch of other things, like the MacBook Air, Transactions and well … dirt.

Check it out

I was complaining to Richard Gaskin of FouthWorld about how LiveCode’s Application Browser showed plugin stacks. I almost never want to see those there. They just get in the way.  Richard convinced me that I could create a Patcher Stack that would solve the problem. So I did.

I created a stack that installs a patch that allows you to Hide any open stacks that are in folder named “Plugins”.  This solves most of the cases although it could be improved.  Once the patch is installed you can toggle the Hide Plugins filter on and off.

This does modify a LiveCode Stack. The file is in /Tools/Toolset/revapplicationoverview.rev.  Although I don’t create a back up, I do provide an uninstaller.  And the script that is modified is clearly marked up so that you can see what was changed.

This my first attempt at patching the LiveCode IDE. I would welcome any feedback Please let me know if you find any issues, by commenting on this post.

if you are in LiveCode just enter this in the message box

go URL “http://files.geistinteractive.net/a/FilterPlugins.livecode

When FileMaker Go first shipped, I wrote about it being a whole new platform. The opportunity that it presented was so big that I thought FileMaker Go would be come the first Platform that I would build for. But in the months after the release, I didn’t even use it much myself. I was curious about this but I didn’t have an answer. Then at Pause on Error I got my answer. Here is the story.

FileMaker Go worked as advertised. I could connect to my databases on my server. I could build interfaces that fit the iPhone or the iPad. But when it came time to actually enter data, I didn’t do it on my iPhone. I waited until I got to my laptop.  Why?

I had a choice. I could wait to use a much faster machine, better keyboard and probably a better network connection. So I waited. This was not a conscious decision. It was just what I did. As a result I used FileMaker Go less and less.
All that changed at pause on error.  I attended a session coordinated by John Sindelar of SeedCode.  During that session we heard from J. Sciarra and James Wesolowski from Colibri Solutions about a system that they built for FileMaker Go. Through trial and error they had come up with a architecture that worked in the real world. And it turns out that the real world doesn’t just involve slower network connections and slower devices. It involves fragile connections and or no connections.  They needed something that worked in all of these scenarios.
So what was their solution? Go Local.  They created a FileMaker Go application that was designed to work on the local iOS device, completely disconnected from any Filemaker server. If you want to know more about why they did what they did, you can check out their DevCon preview video, and or attend their session at FileMaker DevCon 2011.
Now at first, I thought, “Yeah, but then you have to manage the data exchange back and forth from Server File to Local File. Thats too much work”. But as they talked about how they did it, it started to occur to me that the solution they had come up with was one that many *native* iOS apps used. I started looking at the apps on my iPhone and I found that if it was an app that had a server component, it was almost always caching the data locally. Here are just a few:
  • TripIt
  • MiniBooks
  • Runkeeper
  • Contacts
  • iCal
  • Mail
  • Twitter
All of these cache some or all of the data locally until it needs to be refreshed or sent back. They do it so you can still use them when you have a bad connection or no connection. And they do it for speed and responsiveness.  Their UIs are richer and snappier as a result.
Once I realized that Joe and James had independently found the same solution that iOS developers had found I realized that they were almost certainly on to something. My brain literally began to buzz. It just made sense.  Building the best FileMaker Go Apps requires building specifically for the device, using best practices that made sense for the device. This is a very different approach then trying to morph a model that works for desktops on a LAN to one to what that works on iOS devices out their in the real world, which is what i had been doing.  I was convinced, the answer was to GoLocal.
But there are lots of challenges that have to be over come for this to be a viable method for building FileMaker Go Apps. Some are obvious, like exchanging data and deploying local files.  Some are not so obvious, like dealing with shaky 3G connections.  This turns out to be quite tricky to do well.   The guys at Colibri had decided to use us only iPod touches so they could ensure that the users never had to deal with shaky 3G connecting while exchanging data with the server.  This made it easier for them to use import records to exchange data and images with the hosted solution.
I felt that at generalized framework for Going Local would have to work over 3G and be able to gracefully handle sudden disconnects, even in the middle of data transfer.  As the discussion continued at pause, a plan began to form in the back of my head.  I was pretty certain that I new how to handle the 3G connection issue. I couldn’t wait to try it out.
I left pause convinced that this was the way to build awesome FileMaker Go Apps, and that the challenges could be over come with a well thought through architecture. I had some ideas about how to do it, but I needed some help.  So I turned to my long time colleague and collaborator, John Sindelar, and together we have been cooking up some awesome sauce!
Stay tuned for whats next!
And thanks again to the guys from Colibri Solutions for inspiring me to “go local”.

For years I have been using a recursive custom function to get a list of all the Selected Tab Panels on a layout.  This works quite well, but in my current project I wanted to get rid of all custom functions. I didn’t really want to use a looping script. I wanted a pure calculation that could do it.  This is what I came up with.

Evaluate("List(¶"  &
left =  "Let([tab = "";
right = ""];Case(GetLayoutObjectAttribute ( tab ; "isFrontTabPanel" ) ; tab;""));";
tabs = Substitute(
  LayoutObjectNames ( Get( FileName ); Get( LayoutName ) );
left &

   "¶"; right & "¶" & left
) &

This seems to work pretty well.

Apologies, the download file has gone missing.


UPDATE:   I got re-tweeted by Sencha Inc. it blew out my bandwidth at screencast.com. That is totally cool!

I have been doing a lot of work with JavaScript lately. Specifically looking at how to build cross platform mobile web apps that connect to FileMaker.  There are some pretty cool libraries available out there that significantly reduce the works load. I had some time at LAX waiting to fly out to pause on error. So I whipped up this little demo using SeedCode Complete running on my FileMaker server in the Cloud and local <a href=”http://www.sencha.com/products/touch/”>Sencha Touch</a> Application.  Check it out.

One of the interesting things about this app is that it requires no server side code at all.  There is no PHP, no Groovy, no Java, no nothing, other than FileMaker running on the sever.  You can write server side code and that probably makes sense to do so in the long run for anything complex but it is not required. In this demo we are using javascript to connect directly to the XML gateway on FileMaker Server.

Perhaps the most interesting thing about this application is that it will work on any mobile device that has a webkit baked browser  So we are not limited to just iOS devices, like iPhones and iPads.  This will work in on WebOS, Android, Blackberries. Windows Mobile 7 support is around the corner.

And Perhaps I should mention that this is not limited to Mobile devices either.  SenchaTouch is based on on <a href=”http://www.sencha.com/products/extjs4-preview/”>ExtJS</a>, one of the most powerful libraries around for building rich web based applications.

Here is the movie.  Hope you enjoy!

After taking a couple of years off,  I am happy to announce that I will once again be speaking at the FileMaker Developer’s conference.  The 2011 conference will be held in San Diego, CA, August 2-5, 2011 (Tuesday-Friday). I am very excited to be doing this again. I thoroughly enjoy speaking about FileMaker and can’t wait get back up on the stage.

In the past my sessions have often focused on how to use Database Transactions with FileMaker scripts.  Transactions can solve some very tricky issues, so I was very focused on the concept of a transaction, what it was, and how to use them in FileMaker, etc.  But over the years that I have been scripting this way I have seen that these same techniques or very similar ones can solve a broader array of problems.  Script triggers and other newer features also have something to add to this conversation as well.  So this time around, I wanted to loosen up a bit and go deeper.

I decided to focus on the very lowest level in this whole process and dig into exactly how FileMaker decides what data to save and exactly when it saves it.  Armed with this understanding, we can solve a wide array of problems that might otherwise plague complex FileMaker systems.

I titled my presentation “Understanding Commit Record”.

Here is the abstract

FileMaker Pro “commits” data to its database. Normally this process happens in the background, without developers worrying about it.  But sometimes it is very useful to take control of this process so we can decide exactly when and exactly what data gets committed to the database.
In this sessions we will learn the nature of the commit record process and we will see how we can control commits to solve some tricky problems. For exampke; how to mitigate the issue of the iPhone ringing and halting a script in a FileMaker Go application,  how to build interfaces that allow the user to “cancel” the changes they have just made to a few records in the database, elegantly handle multi-user record locking, or even how to speed up large batch operations.
A good solid understanding of the commit record process will carry you a long way towards building better, more robust solutions.
I hope to see you all in San Diego.  If you have any topics you would like me to cover, or issues you would like to see addressed in this preso, just post them to the comments.


Geist Interactive is proud to announce the release of proSign v1.0. proSignp makes it easy to add signature capture to any FileMaker Pro solution. Signatures can be captured using any touch pad or pen and tablet input device. No special hardware is required. It runs on both Mac and PC. It requires FileMaker Pro version 9 or greater.

Signatures are captured and stored as Base64 encoded data urls which makes them easy to display in web viewers or to embed into HTML email. You can also convert these into PNG files later for storage and display using the free GoSignCompanion plugin.

Geist Interactive founder, Todd Geist, said “proSign is a follow up to our proSign for FileMaker Go product. Many of our GoSign customers asked if we could come up with a version that worked on regular FileMaker Pro. proSign is the result.”

proSign is available by itself for $239 or bundled with GoSign for FileMaker go for $289.00. Existing GoSign customers are eligible to get proSign at a special price of $219.00 For more information on pricing and to try out demos, please visit the GoSign web page, http://www.geistinteractive.com/proSign.

Geist Interactive is a FileMaker consultancy known for its creative outside the box style and for its deep knowledge of the FileMaker environment. Todd Geist, Geist Interactive’s founder, has given presentations and training seminars at conferences and events all over the United States and the United Kingdom. Geist Interactive is located in Newbury Park, CA.


Todd Geist – Owner



This post is a direct response to a support request I got from a customer earlier today.  The question was how do you change the size of the captured signature?  It isn’t too hard, but unless people are real familiar with how the web viewer works they might miss some of the key steps.  So I thought I would throw together a little demo file and screen cast to show how  it is done.

First, here is the idea behind the technique.  Remember GoSign captures signatures as Base64 encoded image URLS.  These are also called “image urls”, since the are a “URL” that has the image data in it instead of the image location.  That means that they work perfectly as the “src’ of an image tag.  Image tags also have “width” and height” attributes that can be used to scale an image up or down.  So to re-size our captured signature, all we need to do is embed our image url in an img tag in a web page and set either the height or image tag.

Apologies, the demo files have gone missing.

And here is a screen cast

ARVE Error: id and provider shortcodes attributes are mandatory for old shortcodes. It is recommended to switch to new shortcodes that need only url


Enhanced by Zemanta

I just came across an interesting little FileMaker quirk.  The “Set Variable” script step does not allow you to begin the variable name with a space. But you can declare variables with the Let Statement can also declare variables and they can start with a Space.

For example:

If you try to use the “Set Variable” script step to declare this variable “$$ StartedWithSpace”, it will not let you.  However if you evaluate the following Let Statement:

   $$ StartedWithSpace = "this will work"

It will work just fine.

While this is strange, I am not sure that it useful. In fact my gut tells me it is a bad idea to have variable names start with a space. So I am going to avoid them.

I am very excited to announce my first actual product for sale here at Geist Interactive.  GoSign – easy signature capture for FileMaker Go!  Using GoSign you can add signature capture to any FileMaker Go application in about ten minutes.

The core technique involves using a WebViewer to display a jquery based JavaScript/HTML5 application that lets someone scribble their signature directly on to an iPad or iPhone, just like they do in the Apple store’s now. Needless to say this involves a lot of moving parts.

GoSign Packages all the JavaScript, HTML, and FileMaker logic into some scripts and layout objects, that can easily be moved into your solution.  It requires no changes to schema other than the the field need to store the actual signature data. The integration points are few and well defined.

For more info pricing, and to download a demo, check out the GoSign webpage.

A special thanks goes out to Richard Carlton of Richard Carlton Consulting (RCC) for being customer number 1!