the beezwax buzz : the beezwax buzz | beezwax.net

Native Web 2.0 Controls in FileMaker 12 Layouts

2012-04-17T18:25:11Z

One of the most exciting aspects of the newly-released FileMaker 12 product line upgrade is a major redesign to the product’s UI. A new Design Surface modernizes FileMaker Pro layouts and updates every built-in control, giving developers and designers powerful new tools for designing better interfaces.

But as great as Design Surface is, why just stay on the surface?

Here's how to take advantage of a hidden key in FileMaker Pro 12 to go far beyond the limits of the default set of layout controls. This article will demonstrate how to incorporate virtually any UI control you see on the web directly into your FileMaker 12 Pro — and FileMaker Go — layouts.

Web 2.0 controls and widgets can now be full citizens of FileMaker solutions. They can display FileMaker data as it updates in real time. They can make real-time changes to FileMaker data — natively, without plugins. In short, with FileMaker 12, you can integrate Web 2.0 controls deeply and transparently into your solutions.

HTML5, jQuery, MooTools, ExtJS and more

This new capability opens a door wide to creative possibility. Developers and designers can now expand the palette of available layout controls. If you can find a JavaScript control or an HTML5 design pattern on the web that meets your needs, you can potentially implement it in FileMaker. For example, check out the JavaScript widgets, toolbars and effects available via jQuery, MooTools, or ExtJS. These typically work perfectly in modern browsers. And this technique leverages industry-standard HTML5, JavaScript, and CSS3 - so now you can involve those web designers who might otherwise feel left out of the FileMaker 12 development party.

A Sneak Preview

So, what does a FileMaker 12 layout look like with native Web controls? Here's an example of the end result:

Two native web controls (a single and a dual range slider), plus several standard FileMaker edit box controls (first and last name fields, as well as live text values,) work together to create a simple interactive layout.

A quick note: See the end of this blog post for the demo file. And for now, this technique only works with a solution hosted on FileMaker Server 12, which I'll explain shortly…

Web Viewers that Talk Back

Our ability to fully integrate live web controls into layouts uses FileMaker 12's new “fmp://” protocol. I'll cover the details later in the article. For now, here's the bit we care about: Objects within a Web Viewer can use this new protocol to send messages directly to our FileMaker 12 databases. They can directly call FileMaker scripts and pass parameters to them in real time.

This means that a Web Viewer in our solution can make a round trip cycle and communicate any changes about its state to our solution, just like built-in layout controls always have done. In effect, this turns Web Viewers from display-only portals into full citizens of our FileMaker world. Anything we could see in FileMaker 11's Web Viewer can now potentially talk directly to our FileMaker 12 solutions.

This technique works well in both FM Pro 12 and FM Go 12, with one quirk. As of this writing, this technique using the fmp:// protocol doesn’t work with standalone FileMaker Pro databases, although it works fine with standalone FileMaker Go databases. (So, you may want to make sure you have a FileMaker Server or an iPad handy). Hopefully, this limitation will be addressed with a future release of FileMaker Pro.

Setting Up a Demo Project

Let’s start with a simple FileMaker solution. We’ll track some very basic information about employees and their commutes: daily commute miles, and the minimum & maximum number of minutes their commute can take (say, depending on traffic conditions). Here's our FileMaker Pro 12 layout using standard native controls:

There's certainly nothing wrong with this, especially given the FM 12 Design Surface's new abilities to provide CSS styling and web-like object hover and focus styling. Still, let’s imagine that we want to provide range sliders on our layouts, just like users would see on the web. We want a simple slider for daily commute miles, and a dual/range slider for the daily commute fields.

Choosing from a Vast Menu

When the whole web is our UI oyster, we face a smorgasbord of options. So, let's go pick some Web 2.0 slider controls. For now, we'll limit our world to native HTML5 or JavaScript controls. Also note that Web Viewer in FileMaker 12 for Windows does not support most HTML5 objects (this is expected to change when Internet Explorer 10 is released). Therefore, we'll further limit our search to widgets from widely-used JavaScript libraries we mentioned earlier. One suggestion: If you find a web control you'd like to use in your FileMaker Pro 12 solution, test it in both in Safari (Mac) and IE (Windows) to make sure it works as expected in both browsers.

Setting Up the Basics

Whenever we want to bring a web widget into a FileMaker solution, our first task will be to extract the HTML, CSS and JavaScript required for this control to work. In our case, we’ll start by downloading the code for some range sliders via the excellent jQuery demo site. We'll extract the code, and we'll change any relative paths to be made absolute. We may want to place JavaScript, stylesheets, and other assets into local objects within our solution or onto servers we control and update references to match. Then, we'll package our widget up into a Custom Function which will enable us to easily deploy it in any solution we'd like.

The starting version of our jQuery slider Custom Function is shown below. The code is really quite simple: we invoke some standard jQuery script libraries, add a standard jQuery stylesheet and a bit of inline CSS, and create the jQuery scripting needed to configure a slider for the slider function and a skeletal body structure:

        "data:text/html,

        <!DOCTYPE HTML>

        <html>

        <head>

        <link rel='stylesheet' href='http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/themes/base/jquery-ui.css' type='text/css' media='all'>

        <style type='text/css'>html, body {height:100%;width:100%;border:0;padding:0;overflow:hidden;}#slider-range {position:absolute;width:80%;left:10%;}</style>

        <script src='http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js' type='text/javascript'></script>

        <script src='http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/jquery-ui.min.js' type='text/javascript'></script>

        <script src='http://jquery-ui.googlecode.com/svn/tags/latest/external/jquery.bgiframe-2.1.2.js' type='text/javascript'></script>

        <script src='http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/i18n/jquery-ui-i18n.min.js' type='text/javascript'></script>

        <script type='text/javascript'>

        $(function() {

          $( '#slider-range' ).slider({

            min:0,

            max:100,

            step:1,

            value:5  });

        });

        </script>

        </head>

        <body><div id='slider-range'></div></body>

        </html>"

This is Ground Control to Major Tom…

On our layout, we'll add a Web Viewer set to get its data URL from our Custom Function. This is an important first step where we confirm that our web control acts like it should - in this case, sliding back and forth like a slider. But we haven't yet told our widget how to communicate with our FileMaker solution, so we won't expect any interactivity yet.

Our next step will be to wire up our widget to consume live FileMaker data. We'll begin by adding some script parameters to our Custom Function to give us conduits for passing bits of data to our widget. Then we'll modify our static Web Viewer code so that the data passed through our script parameters will be dynamically injected directly into the widget itself. The new additions to our custom function look like this:

    $(function() {

      $('#slider-range').slider({

        min:" & vmin & ",

        max:" & vmax & ",

        step:" & step & ",

        value:" & value & ",

      }

    });

…This is Major Tom to Ground Control

At this point, our Web Viewer will be able to see FileMaker data and will immediately respond as we change the linked field data. Now let's teach our Web Viewer to talk to our solution. To do this, we’ll add two more script parameters to our Custom Function: These will let us pass the name of the FileMaker script we’d like our web control to call when it’s been modified, and the name of the field we’re binding the control to.

Within our JavaScript code, we'll also make a few changes. First, we’ll attach an anonymous function to our jQuery slider’s “stop” event, which efficiently fires only when we release our slider. When this event fires, we'll do something unexpected: We'll set the location of the Web Viewer itself to a special URL that's nested in that nifty FileMaker 12 fmp:// protocol. This combination of invoking the fmp:// protocol and placing it in the web viewer's location hash is FileMaker 12's secret sauce that will let our web viewers talk directly to FileMaker. This is the most important bit - and perhaps the trickiest as well - so let's break this down a bit:

Within our jQuery code's stop event, we set the Web Viewer's self.location property. The value we use is assembled from a combination of static text and dynamic FileMaker-calculated data. You may wonder where the advertised "fmp://" protocol is. In this case, it's wrapped in a simple Custom Function, whose job is to dynamically create a valid set of arguments regardless of the file's location or platform. We create a Custom Function, "url.fm". It accepts 2 script parameters, "script" (the name of the FileMaker script our web viewer will talk to) and "parameters" (any hard-coded parameters we want to pass to that script):

        Let ( 

        [

        path = Get ( FilePath ) ;

        path_pro = Right ( path ; Length ( path ) - 7 ) ;

        start_go = Position ( path ; "/" ; 1 ; 2 ) + 1 ;

        path_go = "$/" & Middle ( path ; start_go ; 9999 ) ;

        path = If ( isGo ; path_go ; path_pro )

        ] ;

        "fmp://" & path & "?script=" & script & "&param=" & parameters

        )

This Custom Function does a few tasks for us. Most importantly, it determines our platform and the location of the file we're using, and constructs the matching fmp:// URL for us. So in FileMaker 12 Pro, our fmp:// URL will look something like this :

    fmp://10.1.10.100/Integrating_Web_Controls.fmp12?script=my_script&param=my_parameters

While in FileMaker 12 Go, our URL will look like this:

    fmp://$/Integrating_Web_Controls.fmp12?script=my_script&param=my_parameters

Returning to our slider Custom Function, we can now reference url.fm as we're setting the Web Viewer's location property. After invoking url.fm, we'll concatenate code that will append the current value of our slider at the moment the event is fired:

        $( '#slider-range' ).slider({

          min:" & vmin & ",

          max:" & vmax & ",

          step:" & step & ",

          value:" & value & ",

          stop: function( event, ui ) {

            $( self.location = " & 

                  sQuote ( url.fm ( script ; target_field & "|" ) ) & "

                  + $( '#slider-range' ).slider( 'values', 0 )

             );

          }

        });

With this in place, our web widget will now look for the FileMaker script we direct it to via our script parameter, and if it's able to connect, it will pass the live parameters we've set up. We're almost there.

The last thing we need to do is set up the FileMaker handler script our web widget will be looking for. The handler script's task is to take the parameters our web widget hands it and perform whatever action we want. in our case, the action is to update the targeted FileMaker field. Let's set up a script to do this, remembering that our Web Viewer will be returning the name of the field it wants to update as well as the value (and that our upcoming dual slider widget will return pairs of each). Here's how our script looks:

        Set Variable [ $_params; Value:Substitute ( Get ( ScriptParameter ) ; "|" ; "¶") ]

        Set Variable [ $_fields_passed; Value:Case ( ValueCount ( $_params ) = 2 ; 1 ; ValueCount ( $_params ) = 4 ; 2 ; 0 ) ]

        If [ $_fields_passed = 1 ]

          Set Variable [ $_target_field; Value:GetValue ( $_params ; 1 ) ] 

          Set Variable [ $_value; Value:GetValue ( $_params ; 2 ) ]

        Else If [ $_fields_passed = 2 ]

          Set Variable [ $_target_field; Value:GetValue ( $_params ; 1 ) ] 

          Set Variable [ $_target_field_2; Value:GetValue ( $_params ; 2 ) ] 

          Set Variable [ $_value; Value:GetValue ( $_params ; 3 ) ]

          Set Variable [ $_value_2; Value:GetValue ( $_params ; 4 ) ]

        End If

        Set Field By Name [ $_target_field; $_value ] 

        If [ $_fields_passed = 2 ]

          Set Field By Name [ $_target_field_2; $_value_2 ] 

        End If

Houston, We Have Contact!

OK. We've done all the hard work! But, really, this wasn't too hard, right? And remember, this is a one-time setup; once we have the pieces in place, things get nice and easy. Now let's take our web widget out for a spin. Back in our layout, we'll add a Web Viewer and configure it with a data URL that points to our Custom Function like this:

        rangeJQ ( 

          DemoValues::miles ; 

          GetFieldName ( DemoValues::miles ) ;

          DemoValues::miles_min ;

          DemoValues::miles_max ; 

          1 ;

          "webHandler" 

        )

And, just like that, we have a live jQuery slider on our layout! It's attached to our miles field as desired. If we update the FileMaker field data, the slider will update instantly to reflect the change. If we move our slider, our underlying FileMaker field data will immediately update as well. Both objects understand and enforce the same data constraints (minimum, maximum, and even step values). From a user's perspective, there's little if any noticeable difference between stock FileMaker layout controls and our new jQuery slider. Everything "just works"…Sweet!

Giving our Web Slider some Style

There is still one complaint from the audience. (Tough crowd!) Our newborn web control is, well, kind of boxy - maybe even, dare we say, ugly. The great news is that just like native FileMaker 12 Design Surface elements, we can simply style our new web widget with a bit of standard CSS, which we'll add in our Custom Function:

        <style type=”text/css”> 

          html, body {height:100%;width:100%;border:0;padding:0;overflow:hidden;}

          #slider-range {position:absolute;width:80%;left:10px;}

          .ui-slider .ui-slider-handle {font-size:.1em; width:1.2em; height:1.2em;-webkit-border-radius:20px;border-radius:20px;background:#eee;}

          .ui-slider .ui-slider-range {font-size:.1em;background:#85BAFA;}

          .ui-slider-horizontal {height:4px;background:#ddd;border-color:#bbb;}

          .ui-slider-horizontal .ui-slider-handle {height:14px;width:14px;font-size:.5em;top:-.7em;}

          .ui-slider-vertical {width:4px;background:#ddd;border-color:#bbb;}

          .ui-slider-vertical .ui-slider-handle {height:14px;width:14px;font-size:.5em;left:-.7em;}

        </style>

Now our web control looks much nicer:

Completing the Picture

With that under our belt, let’s tackle the second part of this job, and add a multi-range slider. This will go quickly now that we understand the basic steps.

First, duplicate and rename the slider Custom Function, and give it a new name (like "dual slider"). In our dual slider Custom Function, we’ll add a couple of new parameters to our existing slider code, so we can pass in and later return two data values and field names instead of just one. We’ll also lightly modify the jQuery code, so our code will accept and return these 2 added parameters. We won't need to modify our CSS or HTML - they'll work just fine. Back in our layout, we'll add a second Web Viewer and point it to our dual slider Custom Function. Here’s how things now look:

Everything's working great, and our imaginary users are thrilled! But now they'd like the sliders to be vertical, and they'd like to see live, editable FileMaker native controls interact with our jQuery sliders. No problem! We just lightly modify the JavaScript in our Custom Functions, and fine tune the inline CSS a bit. Easy peezy. Back in our layout, we just resize our Web Viewers for vertical orientation, do a bit of layout adjustment, and we're done:

Where to Go from Here

Once the initial path is paved, Web 2.0 controls and widgets are simple, expressive, and fun to use in FileMaker 12. You'll certainly want to do some prep and planning when you're selecting and setting up a new web control. But once you've configured a control as a custom function, you'll be able to simply drop this web control directly into any Filemaker 12 solution.

This technique opens a doorway to a world of possibilities previously unavailable to the FileMaker development and design communities. For those of us who've long been limited to a handful of possible Ui controls, the ability to simply locate, adapt, and integrate virtually any control we can find on Web 2.0 world can be quite a revelation. We suddenly have the ability to implement sophisticated controls and rich design patterns that have until now been beyond our reach. Exciting stuff!

Please check out this demo file: Integrating_Web_Controls.fmp12.zip. Remember that at this time, this technique requires a hosted or shared solution for FileMaker Pro users; the round trip functionality will NOT work if you open locally in FileMaker Pro. It will work with a standalone or hosted file in FileMaker Go (and if you made it this far, you deserve to buy yourself a brand new iPad!)

If you have any feedback, questions, or ideas, I look forward to hearing from you.

- Brian

FileMaker 12: Exciting New Possibilities

2012-04-04T18:48:27Z

FileMaker, Inc. introduced the next generation of their database platform today with the release of FileMaker 12. This is a major upgrade to every part of the FileMaker product line. There are new versions of FileMaker Pro, FileMaker Pro Advanced, FileMaker Server, FileMaker Server Advanced, and FileMaker Go - which is now free for iPhone and iPad.

With a powerful new file format and a broad range of major improvements, FileMaker 12 offers a whole new set of possibilities to developers and users alike. FileMaker 12's exciting new features will enable your solutions to be faster, more powerful, more robust, more extensible and more enjoyable to use.

First, Some Thoughtful Consideration

As upgrades go, this one is fairly smooth, though not completely without some technical considerations. FileMaker 12 has a new file format, and converting a raw database from FileMaker v7 through v11 can be done automatically. However, to implement FileMaker 12, you'll need to upgrade FileMaker Server and all FileMaker clients at the same time that you convert your older files. Also, existing plug-ins may not work without updating by their developers.

And of course, you may want some help with custom development to take advantage of many of the new features. If you feel it's a good time to take a deep look at what your current databases are doing, and how they can take advantage of FileMaker 12, please get in touch with us.

Now, The Exciting New Possibilities

Not sure if it's time to make the jump to the new version? We offer this perspective - a list of the top new features we've found the most exciting in FileMaker 12:

A Better Foundation: FileMaker Server 12

Most shared FileMaker solutions are deployed using FileMaker Server. We're thrilled that FileMaker Server 12 features several core enhancements that make it significantly faster and more reliable. Most notably, it has been re-architected so that functionalities like serving data, web publishing and backup run in separate, independent processes. Now you can have more peace of mind knowing that mission-critical solutions will be less susceptible to slowdowns, hangs, or whatever else technology throws at you.

More Speed? Yes, Please!

FileMaker Server is now a 64-bit application. FileMaker Pro and Server are now 64-bit applications. This means that it can leverage much more of your hardware's available resources. FileMaker Server will also perform backups incrementally, which leaves more of those resources available to users. Key operations like finding and sorting records have been optimized to minimize network traffic. You'll notice that functions like finds and dynamic value lists are much snappier over the network in FileMaker 12.

Those of you looking at web front-ends to your FileMaker solutions will be encouraged to know that FileMaker 12 re-architected the web publishing engine. Our tests thus far have been very encouraging, especially improving speed when multiple users are involved.

Developers can garner further speed gains using new features like the light-weight CSS-like interfaces, SQL queries (see below), and the new container storage and file management features.

FileMaker Now Understands SQL Queries

FileMaker now natively exposes its tables to queries using Structured Query Language (SQL). Even if you don't know SQL, you'll appreciate the major boosts in power and speed that it this can bring to a solution. Developers will be even happier to find that SQL can make FileMaker-based systems much more compact and robust under the hood. The beauty for the users is that less code generally results in systems that are faster, more dependable and easier to maintain.

Making Your Media Safe and Accessible

This is a tremendous update for anyone dealing with images, videos or documents. FileMaker 12 will let you view light-weight thumbnails and even stream your content for fast viewing. It also allows you to store "container field" data in linked files, optionally encrypted, on the hard drive. This can drastically reduce the size of your database and decrease load times. Just drag your file into a container (yes, drag-and-drop was added too) and let FileMaker do the rest!

In Style With CSS

Good designers will tell you that aesthetics are an integral component of function. FileMaker 12 provides an entirely new layout design surface that brings a modern, Web 2.0 feel to layouts. Under the hood, layouts are now being styled with Cascading Style Sheets (CSS) – the visual language of the web. Layout objects are still configured with graphical tools, but this web-like design approach provides developers with the tools to create much more polished and interactive user interfaces. You'll notice new details like rounded corners, gradients and on-hover effects becoming a natural part of your solutions.

More Charts, At Your Fingertips

Decision-makers love charts. Charts have a way of distilling large sets of data into something compact and easily digestible. FileMaker 12 provides an all-new Chart Wizard, complete with previews and brand new chart formats (Stacked Bar, Positive/Negative Column, Scatter, Bubble). Users will be pleased to discover that they can even create ad hoc charts by right-clicking in a field in Table View.

Going Mobile Has Never Been Easier

The speed gains in FileMaker 12 are very pronounced in FileMaker Go on the iPhone and iPad. We've tested iPad solutions that, as they are being deployed, can shave hours of work off of workflows in the field. FileMaker Go 12 improves how security, multitasking and other native iOS functions can be used. And to top it all off, you can download FileMaker Go for free on iPhone or iPad!

The Bottom Line

The FileMaker 12 family brings many new features that can make your systems more robust and more enjoyable to use. It's an exciting release, particularly for anyone looking for better media management, mobile support, network performance or simply a more stunning-looking solution.

As much as we still love FileMaker Pro 11, this is a major improvement all around. We're particularly excited that the result of FileMaker 12's new power, speed, and reliability isn't just databases that can do more, but databases that are even more exciting to develop, and more enjoyable for users to use every day.

Enjoy the new possibilities of FileMaker 12!

- The Beezwax Team

Open a remote FileMaker file with AppleScript

2012-02-23T01:29:01Z

I needed to run some FileMaker scripts on a regular basis. For a few reasons, but mainly because the scripts create PDF files, I couldn’t run these using a scheduled script on the server.

This at first seems like a pretty trivial task. But the file is hosted remotely, and accessed over a VPN connection. Coupled with the fact that the system is quite large, and the ‘bot only being modestly powered, I was getting some very slow load times. Among the issues were the time outs I was getting from operations taking longer than the 60 seconds given by default for an application to respond to a AppleScript request.

In retrospect, I would’ve been better off using an AppleScript that simply opened a .fp7 launcher file (a local FileMaker file that opens a remote file). But as I said, I at first thought this was going to be pretty trivial. And there is one advantage to this approach – I could attempt to handle some situations where a dialog pops up (e.g., “You have been disconnected from the server…”) that locks FileMaker into a modal dialog until someone clicks through them.

Below is my resulting script. Consider it a work in progress, and I may update it later. It is tested to work with FileMaker 11, but should work with FileMaker 10 despite some subtle differences between how (or when) the two version return their results.

set errorFlag to false
set dbName to "your_db_name" -- name of your database file here.
set hostName to "server.example.int" -- host name of your FileMaker Server here
set msgLog to ""
set maxOpenTime to 80 -- Max time to to get the file open (but before running file's initial scripts)
set maxInitTime to 20 -- Max time required after opening for FMP to become idle.

--
--   l o g _ m e s s a g e
--

on log_message(msg)
    if my msgLog ≠ "" then
        set my msgLog to my msgLog & return & (time string of (current date)) & ": " & msg
    else
        set my msgLog to (time string of (current date)) & ": " & (msg as text)
    end if
end log_message

--
--   o p e n _ f i l e
--

on open_db(hostName, dbName)
    global maxOpenTime, maxInitTime
    
    with timeout of my maxOpenTime seconds
        tell application id "com.filemaker.client.advanced"
            try
                getURL "FMP7://" & hostName & "/" & dbName
                delay maxInitTime -- Give FMP lots of time to finish opening file
            on error msg
                -- if file is already open but busy we may get a "Data is being accessed..." error
                my log_message("open_db: " & msg)
                delay 5
            end try
        end tell
    end timeout
end open_db

--
--   c h e c k _ f o r _ d b
--

on db_is_open(dbName)
    global maxOpenTime
    
    with timeout of maxOpenTime seconds
        -- Change to "com.filemaker.client.pro" if not using Advanced.
        tell application id "com.filemaker.client.advanced"
            
            -- one or more databases are open, but can we actually see ours?
            try
                -- Try something really simple.
                get version
                
                -- Now see if we can get what we really want.
                set dbList to name of every database
                
                -- This may just return a string if only one DB is open, so we need two seperate tests.
                return (class of dbList = list and dbList contains dbName) or (class of dbList = text and dbList = dbName)
            on error msg
                -- May end up here because there are no databases open, or by a "Data is being accessed..." error.
                my log_message("db_is_open: " & msg)
                return false
            end try
        end tell
        
    end timeout
end db_is_open


--
--  click_thru_dlog
--

on click_thru_dlog()
    tell application "System Events"
        tell (first process whose creator type is "FMP7")
            set frontmost to true
            click button 1 of window 1
        end tell
    end tell
    delay 0.5
end click_thru_dlog

--
--   o p e n _ f i l e m a k e r
--

-- Launch and activate the FileMaker client application.

on open_filemaker()
    
    try
        -- This is our first whack at getting FMP started.
        tell application id "com.filemaker.client.advanced"
            activate
        end tell
    on error msg
        -- Didn't work out, log our error.
        log_message("open_filemaker: " & msg)
        
        -- Check that we aren't stuck on a dialog.
        click_thru_dlog()
        
        try
            -- Second try to get it running
            tell application id "com.filemaker.client.advanced"
                activate
            end tell
        on error msg
            log_message("open_filemaker: " & msg)
            return 1
        end try
    end try
    
    log_message("open_filemaker: Filemaker now open")
    return 0 -- success
end open_filemaker


------------------------------------------------------

--
--   m a i n
--

if open_filemaker() = 0 then
    -- Is the database already open?
    if not db_is_open(dbName) then
        -- Try opening the first time.
        open_db(hostName, dbName)
        
        -- Still not open?
        if not db_is_open(dbName) then
            -- One more try at opening the file.
            open_db(hostName, dbName)
            -- If file still not open then we set error flag.
            set errorFlag to not db_is_open(dbName)
        end if
    end if
else
    -- Couldn't even get the FMP client open.
    set errorFlag to true
end if

if errorFlag then
    display alert "Error communicating with " & dbName message "While testing for " & dbName & " access got the following error message:" & return & return & msgLog as critical giving up after 300
end if

Recipe for testing JDBC connection to FileMaker Server

2012-01-25T00:17:02Z

FileMaker Server Advanced allows external systems to connect to its hosted database files via ODBC and JDBC. The remote systems can then run SQL commands against the hosted databases. Often the hard part is getting all the infrastructure ready for this. That includes the correct extended permissions on the FileMaker database file, needed drivers, firewall settings, etc.

FileMaker provides a test program you can use to check if a JDBC connection is working. It is a bit buried on their site, but can be found at: JDBC Test Application

However, it has come up several times that I needed to provide some working Java code that shows how to set up the connection. FileMaker has also provided us with a code fragment showing how this is done on page 31 of their ODBC and JDBC Guide. However, it doesn’t copy and paste cleanly, and it isn’t immediately obvious what needs to be changed to configure it for your system.

While I’m at it, we would really like a step-by-step list of what needs to be done to get this working. So here we go…

• Download the latest JDBC driver for Filemaker, currently at Software Update: FileMaker 11.3.76 xDBC Client Drivers

• For Mac OS X, it is recommended to copy the fmjdbc.jar file into the /Library/Java/Extensions folder. For Windows, there is no prescribed place for this, it just has to be somewhere in your Java classpath. See Wikipedia for more details on Java’s classpath, but simply putting it in the same directory as your Java could should suffice.

• Download the test program’s source code here: FilemakerJDBCTest.java

• Edit the file to use the correct hostname or IP address for your FileMaker Server, as well as the database, user account, and password.

• In the Terminal or DOS prompt, cd to the directory containing the FilemakerJDBCTEst.java file.

• Type javac FilemakerJDBCTEst.java to compile the test program.

• Type java FilemakerJDBCTest to finally run the program.

If you’ve made it this far without problems, there’s a fair chance you should now see the No warnings message from the connection attempt.

Simon.

99 Bottles of Beer Challenge

2011-12-09T19:23:14Z

Here's a fun little challenge for your Friday afternoon. You can do it at home, in a bar, or hopefully even at work. Best of all, it's technical and creative. Your task, should you choose to accept it, is to produce the lyrics to 99 Bottles of Beer in your favorite programming language. I chose to do the solution below in FileMaker. See 99-bottles-of-beer.net for the official challenge details.

The Joy of Diversity

The diversity of what you can do given the same constraints is fascinating. Variations within the same language can be very revealing. In fact, some people use basic problems like this to evaluate the proficiency of programming candidates. But there's much more discovery to be had! Studying other languages is a great way to expand your perspective and capabilities. There are 1436 different programming languages and variations represented on the challenge site, including solutions in AppleScript, Ruby, Malbolge (give me an aspirin!) and even Piet (what!?). My personal favorite is this solution in Perl (believe it or not, it works!).

99 Bottles of Beer, the FileMaker Version

Jon Rosen submitted a solution using FileMaker 3 back in 1996. FileMaker has come a long way since then, although text handling is a fairly static feature set. I couldn't help but throw together my own version (see below). This attempt strives for a standard balance between reliability, extandability, conciseness and readability.

So how would you do it? We'd love to see more examples. The guys at 99-bottles-of-beer.net sound pretty backlogged, but hopefully you can post a link below in the comments. I've also attached a demo file for you to play with.

-Donovan

FileMaker demo file

# PURPOSE: Generates lyrics to 99 Bottles of Beer. See http://99-bottles-of-beer.net.
# HISTORY: Created 2011-Dec-08 by Donovan Chandler
# NOTES:
# 	Displays how FileMaker is relatively intuitive and foolproof
# 	This is actually a textual approximation of a graphical-based UI
# 	Original number of bottles can easily be adjusted in $_total
#
Set Variable [ $_total; Value: 99 ]
Set Variable [ $_rep; Value: $_total ]
Loop
	Exit Loop If [ $_rep < 1 ]
	Set Variable [ $_status; Value:
		Let ( [
			status = $_rep & " bottle" & If ( $_rep ≠ 1 ; "s" )
			];
			status & " of beer on the wall, " & status & " of beer."
		)
	]
	Set Variable [ $_action; Value:
		Let ( [
			num = $_rep - 1 ;
			status = If ( num = 0 ; "no more bottles" ; num & " bottle" & If ( num ≠ 1 ; "s" ) )
			];
			"Take one down and pass it around, " & status & " of beer on the wall."
		)
	]
	Set Variable [ $_lyric; Value:
		List (
			$_lyric ;
			$_status ;
			$_action & ¶
		)
	]
	Set Variable [ $_rep; Value: $_rep - 1 ]
End Loop
Set Variable [ $_lyric; Value:
	List (
		$_lyric ;
		"No more bottles of beer on the wall, no more bottles of beer." ;
		"Go to the store and buy some more, " & $_total & " bottles of beer on the wall."
	)
]
#
Set Field [ Table::lyrics; $_lyric ]

Working with Repeating Fields

2011-10-29T18:19:58Z

FileMaker file (click to download)

I began using FileMaker at the spry old age of FileMaker Pro 8, so I've never been through the trenches of using repeating fields to accomplish what can now be done with portals. However, repeating fields still have a variety of uses, and I'm happy to have them in my toolkit.

When I'm working with a repeating field, there are several questions I might ask of it, depending on the task at hand.

What is the nth value?
How many total repetitions does the field have?
How many repetitions contain values?
How many repetitions are empty?
What is the first non-null value?
What is the first repetition number that contains a value?
What is the first null repetition number?
What is the last non-null value?
What is the last repetition number that contains a value?
What is the last null repetition number?
What is the nth non-null value?
What is the list of all values, excluding nulls?
What is the list of all values, including nulls?
What is the list of all values, including only nulls that precede the last non-null value?
What is the list of repetition numbers containing a non-null value?
What is the list of repetition numbers containing a null value?
What is the list of repetition numbers containing a specific value?

That's a lot of questions. And FileMaker only provides us with three repetition-savvy functions to help in answering them. Many of our answers to these questions will be similar to (if not identical to) the answer if we asked the same question of a list, because a repeating field is a type of list. However, as a special class of list, a repeating field cannot always be interrogated in exactly the same way.

Let's tackle each question one at a time. I'm going to hop around a bit, answering the easy questions first. For all questions, we'll be looking at TABLE::FIELD, partitioned into 10 repetitions, and with the following values.

1. What is the nth value?

Simple. We use the native function:

	GetRepetition ( TABLE::FIELD ; 3 )

returns

	green

2. What is the list of all values, excluding nulls?

Also simple, as List operates on a single repeating field much as it operates on related data.

	List ( TABLE::FIELD )

returns

	blue
	green
	red
	yellow
	yellow
	pink

Now that we've turned the repeating field into a simple list, we can easily answer the next few questions.

3. How many repetitions contain values?

	ValueCount ( List ( TABLE::FIELD ) )

returns

But even better:

	Count ( TABLE::FIELD )

returns

4. What is the first non-null value?

	GetValue ( List ( TABLE::FIELD ) ; 1 )

returns

	blue

5. What is the nth non-null value?

	GetValue ( List ( TABLE::FIELD ) ; 3 )

returns

red

6. What is the last non-null value?

We could continue to leverage our previous solutions, to come up with something like this:

	GetValue ( List ( TABLE::FIELD ) ; ValueCount ( List ( TABLE::FIELD ) ) )

returns

	pink

But better to use the second of FileMaker's native repetition functions.

	Last ( TABLE::FIELD )

returns

	pink

Okay, that's it for the easy ones. The rest we'll need to work for. This next question will ultimately result in our most important function. As we get into more complicated questions, we're going to use recursion to traverse the list; and we can't use recursion unless we have an upper limit to describe our exit condition.

7. How many total repetitions does the field have?

There are several ways to attack this question. First, we could just hardcode the value, since this is a schematic configuration and can't change at runtime. Second, we could put the fully extended field on a layout somewhere, then detect its repetitions using FieldRepetitions. But let's find something more elegant.

	FieldType ( Get ( FileName ) ; GetFieldName ( TABLE::FIELD ) )

returns

	Standard Text Unindexed 10

So we're in luck. This design function suffixes the field description with the maximum defined repetitions.

	GetAsNumber ( FieldType ( Get ( FileName ) ; GetFieldName ( TABLE::FIELD ) ) )

returns

Not only does this work on calculated and summary fields, but it also works on fields with only one repetition. This formula is useful enough that we'll store it in a custom function, FieldReps ( field ).

8. How many repetitions are empty?

	FieldReps ( TABLE::FIELD ) - Count ( TABLE::FIELD )

returns

9. What is the list of all values, including nulls?

List is useful for non-null values, because it automatically strips out the nulls. But this can be problematic if we're trying to compare two lists side-by-side; we don't want values shifting vertically. When I was first getting started in FileMaker, I heavily used a function adapted from John Mark Osborne's ListSet. It uses GetNthRecord to traverse a found set, scooping up values, effectively using List on a found set. We'll use a similar approach here. Beginning with the first repetition, and continuing until we have considered each repetition, return the value of that repetition (inserting a carriage return between values).

We'll start with a shell function: RepList ( field )

	RepListLoop ( field ; FieldReps ( field ) ; 1 )

Which in turn calls a sub-function: RepListLoop ( field ; repMax ; rep )

	Case (
		rep > repMax ; ""
		;	Case ( rep = 1 ; "" ; ¶ )
		&	GetRepetition ( field ; rep )
		&	RepListLoop ( field ; repMax ; rep + 1 )
	)

10. What is the list of all values, including only nulls that precede the last non-null value?

There might be any number of reasons why we want to stop building the list when we hit the last non-null value, but let's look at the problem purely from a performance perspective. Assuming we don't care about trailing nulls, we're only wasting cycles by gathering them. And since a repeating field may contain up to 32,000 repetitions, we're potentially saving on tens of thousands of unnecessary recursions.

RepList does most of the work for us, but the problem is detecting an early exit point. I've seen a solution that counts backward from the end until it hits a non-null value, but this approach guarantees one recursion per repetition. Instead we'll incorporate our solution from #3 as a decreasing counter. Every time we process a non-null value, we know we are one step closer to completion; no need to continue interrogating thousands of repetitions if we know we've already gathered all the values we came for.

RepListOmitTrailingNulls ( field )

	RepListOmitTrailingNullsLoop ( field ; FieldReps ( field ) ; 1 ; Count ( field ) )

RepListOmitTrailingNullsLoop ( field ; repMax ; rep ; maxValues )

Case (
	rep > repMax or maxValues = 0 ; "" ;
	Let ( [
		value = GetRepetition ( field ; rep )
	;	maxValues = Case ( IsEmpty ( value ) ; maxValues ; maxValues - 1 )
	] ;
		Case ( rep = 1 ; "" ; ¶ )
	&	value
	&	RepListOmitTrailingNullsLoop ( field ; repMax ; rep + 1 ; maxValues )
	) // end Let
) // end outer Case

So far most of these questions have dealt with extracting values from the repeating field. But if we want to interact more fully with the field, we might instead want to know about the repetition number that corresponds to specific values. This could be useful for exchanging values (e.g. find 'red' and replace with 'brown'), or perhaps for filling in gaps.

The best approach I know to solve these problems is to use recursion. However, recursion can be costly, especially as the number of repetitions grows. So we need to be as efficient as possible. The two main strategies I employ for recursion efficiency are:

Wrapper functions, as we've already seen in the examples above. These are responsible for initializing counters (to make the function easier to use) and any constants (so we never recalculate a constant twice)
Intelligent upper limits, so that we don't continue to interrogate the field even though we've found everything we're looking for.

Consider each of the following questions:

11. What is the first repetition number that contains a value?

12. What is the first null repetition number?

13. What is the last repetition number that contains a value?

14. What is the last null repetition number?

15. What is the list of repetition numbers containing a non-null value?

16. What is the list of repetition numbers containing a null value?

17. What is the list of repetition numbers containing a specific value?

These can all be abstracted (sort of) into the following question: find n repetition numbers matching value x. Using a little syntactical wizardry, we can decide that in the context of n, "*" means find all repetitions, and "" (null) means find the last repetition; and in the context of x, we can decide that "*" means find any non-null, and "" (null) means find any null.

As my custom functions grow in complexity, I find that the biggest challenge is naming my function parameters and Let variables intelligently, so that the code makes sense. In this case, depending on the parameters passed, we need to keep track of the following:

value. What is the user looking for?
matchTarget. How many matches does the user want? Just the first? The nth? The last? All?
matchMax. How many values in the list match the target value? We must re-adjust matchTarget accordingly, because we don't want to look for the 100th match if we already know there aren't any, or are only a few.
matchCount. How many matches have we found so far?

Armed with those parameters, we can quickly traverse the list, looking for matches, and returning one or more repetition numbers, as appropriate.

RepNumber ( field ; value ; matchTarget )

	Let ( [
		matchMax = Case (
			IsEmpty ( value ) ; FieldReps ( field ) - Count ( field ) // Syntax: Null values.
		;	value = "*" ; Count ( field ) // Syntax: Non-null values.
		;	ValueCount ( FilterValues ( List ( field ) ; value ) ) // Specific value.
		) ;
		matchTarget = Case (
			IsEmpty ( matchTarget ) ; matchMax // Syntax: Return last match.
		;	matchTarget = "*" ; matchTarget // Syntax: Return all matches.
		;	matchTarget > matchMax ; "" // If there are fewer matches than sought by targetMatch, return nothing.
		;	matchTarget
		)
	] ;
		Case (
			matchMax and not IsEmpty ( matchTarget ) ; RepNumberLoop ( field ; value ; matchTarget ; matchMax ; 0 ; 1 )
		;	"" // If the target value is not in the list, or there are too few matches, don't waste time searching the list.
		) // end Case
	) // end Let

RepNumberLoop ( field ; value ; matchTarget ; matchMax ; matchCount ; rep )

	Let ( [
		repValue = GetRepetition ( field ; rep )
	;	match = Case (
			IsEmpty ( value ) and IsEmpty ( repValue ) ; True
		;	value = "*" and not IsEmpty ( repValue ) ; True
		;	value = repValue ; True
		;	False
		) ;
		matchCount = matchCount + match
	] ;
		Case (
			match and matchTarget = "*" ; rep // Syntax: we found a value, but should continue to look for more.
		&	Case (
			matchCount = matchMax ; ""
			;	¶ & RepNumberLoop ( field ; value ; matchTarget ; matchMax ; matchCount ; rep + 1 )
		) // end inner Case
		;	matchCount = matchTarget ; rep // We found the value we're looking for.
		;	RepNumberLoop ( field ; value ; matchTarget ; matchMax ; matchCount ; rep + 1 )
		) // end outer Case
	) // end Let

In the sample file at the top of this article, click each of the questions to see the result.

Good Sir William's Heirs

2011-10-06T23:55:35Z

FileMaker file (click to download)

That old Bard, good Sir William, is nearing the end of his life. Having already provided well for his five children, he now seeks to divide his literary empire among his eleven grandchildren:

But Sir William is a mischevious fellow, and wants only to reward grandchildren who meet certain criteria:

Eldest (among all the grandchildren)
Youngest (among all the grandchildren)
Eldest (among the children of the eldest child)
Youngest (among the children of the eldest child)
Eldest (among the children of the youngest child)
Youngest (among the children of the youngest child)
Middle (among all the grandchildren)
Middle (among the children of the middle child)

How will he sort it out, and have some fun in the process? Luckily, Sir William has a copy of FileMaker Pro 11 Advanced on hand. But how should he go about it? Should he script it? No, he's written enough scripts in his lifetime, and he's grown weary of them. Should he construct a web of conditional relationships on the relationship graph? Also a tiresome prospect, as he's woven together so many complex relationships in his time that it will take scholars centuries to unravel the mess.

Okay, then. How about a portal filter? Yes, a portal filter, that clever addition to FileMaker Pro 11 that moves all the idiosyncratic, one-off relationship logic up to the presentation layer. Within short order, Sir William has built a beautiful FileMaker layout to display which grandchildren shall be favored:

But how did he do it? First, he created a table structure to match his family tree:

Both the CHILD and GRANDCHILD tables are sorted ascending by birth year. That should take care of any issue with family being added to the database in an inconvenient order.

The primary problem to be overcome is that when traversing the relationship graph, FileMaker only respects the last sort order in its path. Thus when moving from PARENT directly to GRANDCHILD, FileMaker will respect the sort on GRANDCHILD, but ignore the sort on CHILD. So, it's up to portal filters to identify the favored grandchild.

1. Eldest Grandchild. This one is easy. Because of the sorted relationship, Sir William doesn't even need a portal. He can put the GRANDCHILD::NAME field directly on the layout, and it will display the eldest grandchild.

2. Youngest Grandchild. Sir William needs a portal for this, but not a portal filter. He uses a descending sort on the portal to override the relationship's sort, and presto magico, the youngest grandchild floats to the top.

3. Eldest Grandchild of the Eldest Child. Okay, enough easy stuff; if Sir William wanted easy, he would have stuck to writing tragedies (they practically write themselves!). Time for a portal filter. The calculation below leverages the solution to problem #1 by constraining the list to just those grandchildren who descend from the eldest child. From there, the relationship's built-in sort order floats the eldest to the top.

GRANDCHILD::ID_CHILD = CHILD::ID

4. Youngest Grandchild of the Eldest Child. Same as above, but we apply an overriding descending sort to the portal, as in problem #2.

5. Eldest Grandchild of the Youngest Child. Things are getting a bit trickier. We can use the same logic as in problem #3, but only if we can identify the youngest child. Sir William has been playing around with repeating functions, though, and happens to know that Last ( repeatingField ) works on more than just repeating fields!

GRANDCHILD:ID_CHILD = Last (CHILD:ID )

6. Youngest Grandchild of the Yougest Child. Same as above, but we apply an overriding descending sort to the portal, just like in problem #4, which is just like problem #2. What a breeze! Why didn't Sir William write all his plays using FileMaker syntax?

7. Middle Grandchild. Okay, finally, a problem worth solving. The pre-sorted relationship takes care of putting all of Sir William's grandchildren into the correct order, so all that remains is to grab the middle value out of the list. The two nuances here are to recast the retrieved value as a number, since it was converted to text by List ( ); and to devise a method for dealing with odd/even numbers of grandchildren (more could be born before his will is executed, after all!).

GRANDCHILD::ID = GetAsNumber ( GetValue ( List ( GRANDCHILD::ID ) ; Ceiling ( ValueCount ( List ( GRANDCHILD::ID ) ) / 2 ) ) )

8. Middle Grandchild of the Middle Child. Now Sir William is scratching his skull cap. It's easy enough to identify the middle child, using the same technique as in problem #7. But then how does he constrain the list of grandchildren to just that child before performing an additional operation on the list? Sure he could create some fields to pass blobs of text around, but the whole idea is to use portal filters! What about one of those fancy SQL plug-ins, so he can just employ a schmancy Select statement? Oh, wait, this is the 1600s; plug-ins haven't been invented yet; it's going to need to be a purely FileMaker solution.

Finally Sir William settles on a custom function to help him massage the two lists of data (one of children, one of grandchildren). He's disappointed that he couldn't fit all the logic into the portal filter, but at least the solution exists solely in the calculation engine. First, his custom function: ParallelLists ( list1 ; list2 ; list1Value )

Case (

IsEmpty ( list1 ) ; "" ;

List (

Case ( GetValue ( list1 ; 1 ) = list1Value ; GetValue ( list2 ; 1 ) ; "" ) ;

ParallelLists ( RightValues ( list1 ; ValueCount ( list1 ) - 1 ) ; RightValues ( list2 ; ValueCount ( list2 ) - 1 ) ; list1Value )

)

Then his portal filter calculation:

Let ( [

childIDList = List ( CHILD::ID ) ;

childID = GetValue ( childIDList ; Ceiling ( ValueCount ( childIDList ) / 2 ) ) ;

grandchildIDList = ParallelLists ( List ( GRANDCHILD::ID_CHILD ) ; List ( GRANDCHILD::ID ) ; childID ) ;

grandchildID = GetValue ( grandchildIDList ; Ceiling ( ValueCount ( grandchildIDList ) / 2 ) )

] ;

GRANDCHILD::ID = grandchildID

)

And with that, Sir William may rest easier, knowing that his FileMaker portal filters are ready to adapt to any changes in his family tree. May his grandchildren grow up to be as nefarious as he!

Here's a quick summary of the techniques employed for each problem:

Version 0.50 of bBox Now Available

2011-10-07T22:30:13Z

A new version of our free bBox FileMaker plug-in is now available.

Perhaps the most interesting addition for this version is the bBox_EvaluateList function, which is defined like so:

bBox_EvaluateList (values; expression {; delimiter} )

This syntactic construct is also available in Python and JavaScript, and is a convenient way of processing items in a list. As the function iterates through each item of the list, two variables are set. $i will contain the current item index (i.e., which item number in the list of values), and $v will be the value itself. The results for every item are concatenated to form the the function's result. Here is a trivial example:

bBox_EvaluateList ("a¶b¶c"; "$v")

That would give us the result of:

"abc"

The fact that $v is in quotes may seem weird, but remember that the function is getting passed a string expression to be evaluated for each item in the list. Essentially, it is calling FileMaker's built-in Evaluate function. There are of course other ways of doing this sort of thing using recursive custom function calls, but they are slow and limited in the number of values you can process. The case where the data contains quotes has also been handled, but the escaping of such things as quotes can still get a little tricky. Take this slightly more elaborate version of our previous example:

bBox_EvaluateList ("a¶b¶c"; "$i & \\\": \\\" & & $v & ¶")

returns the following:

	1: a
	2: b
	3: c

The elaborate escaping sequences were needed in order to get FileMaker to compile the expression with the quotes inside the string. However, it is hopefully evident that it was worth the trouble to get the result.

Also new are the bBox_ListFields and bBox_ListTables functions. These are convenience functions that give schema information in a MySQL format. The detail however is somewhat limited when run on FileMaker version 10 or less. Especially of interest is that the table function finally gives us a way to find the base table name for a TO.

You can download the latest version of bBox at http://www.beezwax.net/download/bbox.

Learn more about the bBox plug-in at http://www.beezwax.net/bbox.

FileMaker Read-only Fields: Lighter, Smarter, Friendlier.

2011-08-14T22:01:24Z

Here's an interesting interface challenge we recently faced: A client needed to place text fields on a layout and fluidly choose which fields would be editable or read-only—the same field might exist in both editable and read-only state on the same layout.

Now, here’s the challenging bit: Each read-only field must have all the same capabilities of its editable cousins—users must be able to scroll, select, and copy text, and the field control must display all rich text formatting entered.

We added one last requirement of our own: Our technique must be lightweight, easily extensible, and must not add meaningless fields to our data tables.

The Candidates

We started out with 4 possibilities—all common techniques in the FileMaker world:

Limiting access using UI field entry controls
Limiting access using FileMaker Security
Presentation using Proxy Calculated Fields
Presentation using Web Viewers

None of these standard techniques met our client’s needs. We had an interesting problem on our hands! In the end we found two solutions that worked. Our path to each of these is described below. But, if you really hate suspense, you can click here to skip directly to our solutions…

Our text fields: Waiting for a technique to make them secure yet friendly.

Exit Stage Left

Putting our heads together, we quickly ruled out two techniques:

Disabling Field entry: Browse mode (via the Inspector palette) worked too well. It prevented users from interacting with a field at all - no scrolling, selection, or copying its contents.
Using Filemaker’s native Security layer to make a field read-only also was too coarse an approach. If a field was read-only, users couldn't edit it elsewhere on that layout.

Calculated Proxy Fields

We considered a widely-used approach: the time-honored technique of using proxy calculated fields for each field to be read-only. For each field to be read-only, you create an unstored calculated text field, and set its calculated value to the desired field. Out of the box, proxy calculation fields are read-only, scrollable, selectable, and they faithfully preserve any text formatting.

So what’s not to love? The problem lies under the hood. This technique solves a UI problem by creating meaningless data fields, cluttering data tables with entities whose only purpose is presentational. This technique might work well at first, but would create clutter and code management issues as a solution grew.

Web Viewers

We also considered using a Web Viewer to display the field. We set the Web Viewer’s source to:

"data:text/html," & [ fieldname ]

This gave us a read-only, scrollable, selectable display of our field data, didn’t require any additional data fields, and was bullet-proof against editing. But the Web Viewer couldn't display rich text formatting, which was a basic client requirement. Close, but no cigarello.

Web Viewers: Tantalizing. But no formatting…

Script Triggers

Beezwax developer Will Baker suggested a simple, elegant script trigger solution: By triggering a simple script that returned false whenever a field’s onObjectKeystroke and onObjectModify events fired, we could prevent any keyboard edits, and allow scrolling, selection, copying, and even format preservation. We liked this technique a lot—it’s elegant, lightweight, requires only 1 trigger script, and would keep our data tables completely clean.

Unfortunately, this technique had an Achilles heel: Users could still edit field data using cut/paste and drag and drop.

A Single Proxy Field

Returning to the idea of proxy calculated fields resulted in a mini brainstorm: We found we could remove most of this technique's usual clutter by creating a single, repeating presentational calculated field able to present any number of fields. We defined our single proxy field like this:

Choose ( Get ( CalculationRepetitionNumber ) ; "" ;
  Extend ( [ field_1 ] ) ;
  Extend ( [ field_2 ] ) ;
  Extend ( [ field_3 ] ) // and so on…
)

This technique would let us keep data tables clean, even as a solution grew. Our read-only field controls could be scrolled, selected, copied, preserve all formatting, and be edit-proof. This could work.

There was just one annoying fly buzzing in our ointment: If users tried to modify the field, a pesky FileMaker warning would pop up every time. The warning message was technically correct; but users would find it unecessarily jarring and confusing.

The dreaded warning dialog. “Stop slapping my hands!”

Our Reese’s Peanut Butter Cup moment came when our two best ideas bumped into each other. We combined the trigger script technique with the single proxy field technique, getting the best of both: No more pesky dialogs if a user typed into a field (the script trigger intercepted attempted changes), and no more sneaky mouse or menu edits (the calculated field prevented these).

This solution is elegant, lean (just 1 trigger script per database, and 1 additional field per table), and robust (it won’t break if field names change). And from a user’s perspective, it “just works”.

Integrated Proxy Field with Triggers: Bullet-proof, pixel perfect.

Web Viewer Redux

As this article was being written, I had an unexpected “aha” moment: Realizing that our discarded Web Viewer had more tricks up its sleeve, I tried wrapping a field in a GetAsCSS() function, defining the Web Viewer’s source like this:

 “data:text/html,” & GetAsCSS ( [ fieldname ] )

And just this simply, the Web Viewer technique was transformed from a discard into an ideal solution — arguably the simplest and most elegant we’d found. With no additional scripts, no additional fields, and no script triggers, this technique preserves all formatting, allows full scrolling, selection, copying, and is bulletproof against edits.

Improved Web Viewers: Lean, Elegant, OS-native.

So Who’s the Real Winner?

We’re calling this a tie. Here are the advantages we see for each technique:

Single Presentation Field with Triggers

Can display non-white backgrounds (Web Viewers always display a white background unless css/html styling is applied separately).
Complex text will exactly match original field (in Web Viewer, CSS-rendered text may vary slightly from that in native FileMaker controls).
Control exactly matches other native FileMaker controls (scroll bars match native FileMaker edit box look and feel).

Web Viewer

Simplest. Most lightweight. Least overhead.
Provides complete separation between data and presentation layers (no additional data or scripting are created).
Provides an OS-native look. For example, a FileMaker Web Viewer on OS X Lion displays the new hiding scrollbar look and feel.

Both these techniques earn a well-deserved place in our toolbox. Which we choose will likely depend on specific project needs and the preferences of a given developer. Which technique do you like best? Please feel free to comment on which you'd prefer, or if you have a different approach to this problem.

Enjoy!

- Brian

Update: To my chagrin, I realied the demo file was never included with this post. Here it is, long overdue:

http://buzz.beezwax.net/files/Improved_Read-Only_Fields.fp7.zip

DevCon 2011 Recap - Design Goes Farther

2011-08-15T16:06:48Z

One of the most valuable aspects of 2011’s FileMaker Developers Conference in San Diego was a far-reaching discussion about the role of design in the FileMaker world. Design wasn’t the official theme of this year’s conference; but it was certainly among the most popular topics. A large number of sessions focused exclusively on design issues:

Ernest Koe of The Proof Group offered two sessions on Interface Design Patterns in FileMaker (Go and Pro), providing numerous examples of innovative, inspiring real-world FileMaker interface design.
Don Levan of Vanguard Solutions presented a detailed session evaluating form design, and a groundbreaking session, “The Fundamentals of Exceptional Interface Design”, an overview of formal design-centered development methodology.
Heather Winkle and Ryan Shelby of FileMaker Inc. led a hands-on “Guerrilla User Research Session” demonstrating real-world techniques for testing user responses to design.
Heather and Ryan also moderated the “Panel of Design Enthusiasts”, offering a lively round table discussion of design issues from the standpoint of 7 accomplished FileMaker developers.
11 additional sessions in the Design track explored an ambitious array of design issues across the FileMaker platform.

These sessions presented valuable techniques from a broad range of perspectives. Even better, by the end of DevCon the discussion coalesced into a new, inclusive view of design that opens this essential aspect of our craft to all of us, developers and users alike. Echoing the official DevCon tagline: How can we "Go Farther" with design?

FileMaker DevCon 2011 Keynote - via @FilemakerPR on Flickr

Varied Approach, Broad Agreement

At DevCon, there were clear differences in how the session speakers articulated their approach to design. Some developers focused more on “philosophical” meta questions of design’s goals, purpose, and even meaning; others took a more pragmatic, business- and results-oriented path, explaining how good design is simply good business, benefitting their costs, profitability, and ensuring long-term client satisfaction.

But it was interesting to see these surface differences give way to a deeper sense of agreement. The more I listened, the clearer it became that these speakers share a deep belief that good design is central to their development practice and their business.

Design as Central

Amidst this consensus was a shared sense that design lies at the very heart of our work as developers. For example, Don Levan’s session “The Fundamentals of Exceptional Interface Design” described a formal development process in which design is present from the very outset of the process — from initial client conversations and early and ongoing sketches of design possibilities shared with clients — all the way to the final delivered product. This approach was reiterated by a broad range of developers.

Design was also seen as essential to how solutions are conceived, refined, and communicated.

“Design is so closely wrapped up in every solution I build that it is not a separate conversation.” — Bob Shockey

Design was again at the heart of how we create satisfying solutions our users will love to use. Even profitability was directly tied to design.

“Design is a differentiator. It shows well. It leads to user success. It attracts more business. Every company in Silicon Valley has seen a strongly positive ROI on hiring designers and improving their design.” — Heather Winkle

Sunrise on San Diego Harbor - via @PDPhotocom

A Polarizing Issue?

The audacity of these developers’ claims was initially surprising. Design, after all, can be a contentious subject, and has often been cast as expensive eye candy or simply unnecessary “fluff”. This raised some interesting questions:

Are these speakers elevating design-oriented developers above “serious” developers (i.e., coders)?
Are they suggesting that every solution needs an “additional” overlay of design to make it “prettier”?
Are they placing surface beauty ahead of “real” programmatic issues, like performance, speed, or data integrity?
Are we expected to spend all our time worrying about pixels, colors, and fonts?

All We Are Saying…

The more I reflected on these sessions, the more confident I became that the old battle lines don’t apply to this new conception of design. In some ways, this is because the industry itself has changed, and many of the old “rules” have changed with the ascendency of web and mobile technologies.

“A minimum level of design used to be enough … The overwhelming success of iOS, the growing acceptance of web standards, and the sophistication of the user base has significantly raised what is considered acceptable. Indeed, applications and websites that look amateurish or are broken are viewed with contempt and distrust.” — Don Levan

On a deeper level, the old battle lines between “design” and “code” may no longer apply because these speakers are in fact suggesting something more profound than at first meets the eye. Yes, design is now brought into the heart of our process. But at the same time, design itself is fundamentally changed in the process. The “design” at the heart of this new process is not the same design we thought we knew.

Redefining Design

Listening to these speakers, I heard several good examples of what this new conception of design is not. Design is no longer:

A solitary activity based primarily on a “designer’s” individual inspirations, likes, and tastes
A product to be “presented” to users as finished and complete at the end of a development cycle
An optional “nicety” that can be “added onto” a project a la carte

Instead, the new definition of design points towards something much more conversational, informal, a shared process of exploration between developers and users. A new kind of process was described that is:

Flexible and adaptable
Inexpensive and “lo fi”, with drawings providing “only as much detail as we have certainty”
Based directly on established design patterns
Aimed directly at well-defined user personas, scenarios, and requirements
Encouraging refinement, changes of direction, until we arrive at exactly what meets our users’ needs

“Design is the business of creating an optimal user experience within a set of constraints.” — Ernest Koe

FileMaker as a Craft

It was particularly intriguing to hear FileMaker design described as a craft. This wasn’t a mere figure of speech: As described by Don Levan and Ernest Koe, FileMaker design is a genuine craft. FileMaker development can — and should — be conducted through a formal methodology, using defined tools and a known, repeatable process. This vision of formalized craft offers several benefits:

A repeatable way for a developer to design satisfying, effective solutions
A known process that removes the mystery from the design process
A means of recasting design from a product into a process and conversation with users
A core discipline offering developers and users a common language and a framework for achieving success

“If a potential client doesn’t want time spent on the design of the project, it’s not just that we don’t do the project, it’s that we wouldn’t know how to do the project.” — Doug Gardner

We Are Designers

One final aspect I particularly liked about this vision is how it seeks to democratize design. In DevCon sessions, there were constant, explicit reminders that design is all around us — in our architecture, our food, in print, in the natural world. And, of course, design is present in the computing tools we use and build daily.

“Design is everywhere. Good, excellent, bad, horrifyingly bad. I can learn from any of these.” — Bob Shockey

The most revolutionary claim of these speakers may be that, as developers, we cannot avoid this simple fact: Whether we acknowledge it or not, we are designers. Every solution we create is already a design. The question is:

Will our designs create beauty and solve our users’ problems beautifully and elegantly? Or will we develop solutions based on our own long-established preferences and habits, expecting our users to just “get it”?

This vision removes the capital “D” from “Design”. Design ceases to be a product, and becomes a process shared by developers and users alike. And the result of this transformation, as several DevCon speakers frequently reminded us, is empathy for our users: The pursuit of design excellence becomes a pursuit of creating solutions that fit our users’ real-world needs as closely and simply as possible.

“Design is an intentional process in which you elicit, derive, decide, clarify, and plan the solution to a given problem. Sketches, prototypes, technical plans, and finished solutions are the artifacts that result from a design process.” — Don Levan

San Diego Harbor - via @PDPhotocom

The Road Ahead

The conversation about design begun at this year’s DevCon was exciting and full of inspiring possibilities. I left with several questions to ponder:

How will this vision help us develop solutions that are more transparent, intuitive, and effective to our users?
How can we merge FileMaker’s strengths and the insights of the wider design and web communities?
How will the application of these principles affect the evolution of the FileMaker product line itself?

In the weeks and months ahead, I anticipate that my fellow developers at Beezwax and the broader FileMaker community will continue to explore many of these ideas about design and ask how we can integrate them into our development process to "Go Farther" with FileMaker. What do you think?

- Brian

Special thanks to Don Levan for kindly providing detailed speaker notes from the Panel of Design Enthusiasts session.

Inspired by Address Book - Part I: Hiding portal scroll bars

2011-07-18T03:16:43Z

On vacation, waking up to a dreary Pennsylvania morning...

I found myself staring at the OS X Address Book and wondering, "how did they do this?" I couldn't help compare this little application to the many FileMaker-based contact management solutions I have seen, and concluding, a bit sadly, Apple's is nicer.

Now, comparisons between OS X-native code and FileMaker Pro are not always fair to begin with. However, I felt the Address Book presented some useful ideas and perhaps a starting point for a different kind of FM-based contact management solution—one that looks and behaves more like Address Book!

So the journey began...

Got white space? Hiding the portal scroll bar...

Once I got started, I realized I would need to work on making FileMaker Pro feel different. Because I really like all the white space of Address Book, one of the first items I tackled was how to make the portal scroll bar disappear if there were no additional records to display.

Image: Portal scroll bar - showing (left) and hidden (right)

Assuming the portal position is set to enlarge vertically and show additional portal rows, here's a custom function I came up with:

cf_HidePortalScroll ( dph; dprc; dwch; id_portalRecord )

/* 

cf_HidePortalScroll ( dph; dprc; dwch; id_portalRecord )

Use in Conditional Formatting on transparent object
 placed over portal scroll bar, so if Result is "1" make
 the object Fill = White (hides portal scroll bar)

Assumes portal is set to enlarge vertically while
 maintaining original row height - i.e. display
 additional portal rows when it grows vertically. 

 Dependencies: 

   Portal Layout Object Size

   Default # of Portal Rows Displayed

   Default WindowContentHeight

 Road Map:

   dph = default portal height as layout object

   dprc = default portal row count

   dwch = default window content height

   id_portalRecord = ID_Field in Related Portal Table

*/

Let ( [

 hpr = dph/dprc ;
 // height per portal row

 tdr = Count ( id_portalRecord ) ;
 // total portal rows with data

 cwch = Get ( WindowContentHeight ) ;
 // current window content height

 diff = cwch - dwch ;
 // has window content height changed from default?

 tvr = If ( diff ≥ hpr ; ( diff / hpr ) + dprc ; 0 ) ;
 // total visible rows, has content grown > one row's height?

 hr = tdr - tvr
 // if hidden rows exist, don't hide portal 

] ; If ( hr > 0 and tdr > dprc ; "" ; 1 )

) // end let

Afterwards, I found that others had tackled this particular problem before me, but I still like my custom function best—easy to grok, very quick to implement, and doesn't rely on object names. It doesn't work with filtered portals, and it does rely on the physical size of portal object, and number of rows displayed in layout. It also depends on the default WindowContentHeight, so please adjust the sizing to fit your needs.

Next post: Getting records from FileMaker Pro into and out of OS X Address Book without plug-ins, or 3rd party-ware.

Cheers!

-David

The FileMaker Ninja's Toolbelt: TextMate Bundle

2011-07-27T19:34:11Z

Welcome to the first installment of The FileMaker Ninja's Toolbelt, an occasional series on various tools and techniques for taking your development in FileMaker to the next level.

Beyond the Calculation Dialog

The calculation dialog in FileMaker Pro is great for many things. It provides easy access to all of your fields, operators and functions. The Data Viewer in FileMaker Pro Advanced even shows you the calculation results.

Here's a screenshot of a custom function being defined in FileMaker Pro's native dialog:

But sometimes this can be cumbersome. The calculation dialog doesn't help format your functions and can be difficult to scroll through. Those of you who work in text editors know what I'm talking about. Text editors commonly provide users with a host of powerful features: syntax highlighting, code folding, easy indendation, code snippets, find and replace (even with regular expressions), and so on. That's why I develop my custom functions in a text editor whenever I can.

A Text Editor that supports FileMaker Pro?

The problem is that there aren't any text editors that support FileMaker calculations. Or are there? Those of you who already use TextMate might be a step ahead here. TextMate is a very popular text editor for Mac OS X. Best of all, you can easily teach it how to work with FileMaker calculations by installing a FileMaker "bundle" (similar to a plug-in).

There has been at least one bundle available that supports FileMaker. Charles Ross posted one to Google Code back in 2009. At some point Jonathan Stark added some snippets. Matt Petrowsky later posted a trimmed-down version of that to github. Those versions provided some helpful features:

Syntax highlighting
Code snippets
Command for viewing function documentation

Very useful! I forked a copy of Matt Petrowsky's bundle back in March of 2010. I found it so useful that I have been gradually adding to it ever since. Here's a list of the current features:

Tab triggers for FileMaker functions
Documentation for functions, script steps and error codes
Commands
- Manipulating/generating calculations
- Manipulating/generating FileMaker clipboard XML
- Extracting data from the DDR
- Extracting data from import.log files
Syntax highlighting
- FileMaker
- FileMaker Clipboard
- FileMaker Log
- FileMaker Hash (Generated using #( ) custom function from six.fried.rice)
Code folding
Help section

This is what it could look like when working with the same custom function, but in TextMate!

Much more readable, isn't it? You can even change and customize the theme of this window to your exact color preferences. But that's just the start.

You can see it in action by watching this video: TextMate Bundle for FileMaker 01: Basics

Getting It For Yourself

Interested yet? Pretty powerful stuff! The bundle is available to anyone. All you need is a copy of TextMate and to download the files. TextMate even offers a free 30-day trial. You can download the current files and view installation instructions here.

Alternatively, you can just download a recent copy of the bundle below. Just extract the filemaker.tmbundle package from the .zip file and double-click on it. TextMate will take care of the rest!

TextMate_Bundle_for_FileMaker_2012.01.09.zip

Have you tried this bundle or something similar? Let me know on github or in the comments here. I'd love to make this an even richer community effort and resource!

- Donovan

11 Tips for #FileMakerDevCon '11

2011-07-28T00:06:38Z

As you may know FileMaker DevCon 2011 is just around the corner. In honor of 2011...and FileMaker Pro 11, here's our list of Top 11 Tips for DevCon '11:

1. Bring a sweater

Those hotels are known for cranking up the A/C. Take a comfortable layer that you can slip on and off easily to ward off the shivers as you're sitting all morning.

2. Don't expect to find any outlets in the conference rooms

If you're lucky enough to have a second battery, bring it! Maybe you're thinking of bringing an extension cord. I'm not going to discourage you, but don't tell the fire marshall it was my idea.

3. Get a schedule

You can get a copy of the schedule in several forms. There's the conference binder, of course. But, c'mon ... this is a technology conference! Try downloading the schedule in iCal format from SeedCode or download FileMaker's official DevCon2Go Scheduler for, you guessed it, FileMaker Go or FileMaker Pro. DevCon2Go boasts schedule filters, presenter-based views, in-system evaluation forms and even Twitter integration!

4. Tackle one or two big questions

It's easy to leave a conference with way too much information and nothing to do with it. Determine ahead of time what you're going to tackle — something important or exciting to you right now — and learn everything you can about that topic. You're also likely to find a vendor or fellow developer who has encountered the same issue you're mulling over. Have your questions and ideas ready!

5. Don't feel like you have to go to every session

There's so many exciting ideas being presented at DevCon, it can be tempting to pack your schedule with session after session. Don't do it! You're not likely to remember half of what you hear. You're much better off focusing on a few primary themes and building relationships. Those relationships may carry on long after you've forgotten what you heard in the last session. Plus, you're likely to learn even more from one great discussion than you are from a generic presentation.

6. Find out who the popular speakers are

You may still be interested in particular topics, which is great. But make a point to find some speakers that interest you as well. Some people have enough knowledge and/or teaching ability that the topic is irrelevant; you're sure to learn either way. Ask around if you're not sure who those people might be for you.

7. Seek conversations

The FileMaker community is incredibly friendly. Don't be afraid to say "Hi", even to the people who appear to be the big shots. This conference is as much about establishing relationships as it is about sharing information. And remember your business cards.

Another great resource is the topic tables. Sometimes they'll have signs posted on the tables indicating that everyone who sits there is interested in a given topic. They're a great way to meet people with common interests.

8. Embrace the Law of Two Feet

Wikipedia defines the Law of Two Feet:

If at any time you find yourself in any situation where you are neither learning nor contributing: Give greetings, use your two feet and go do something useful. Responsibility resides with you.

That isn't intended to imply that it's not worth sticking around through difficult situations and awkward conversations. The point is that we all bear personal responsibility for making the most out of this conference. If you find yourself in a session that isn't exactly what you expected, politely walk out and find something else to do.

This may be a controversial idea, but it's not a new one. In all fairness to the presenters, please sit near the back if you're not sure that you'll be staying. And fill out an evaluation to provide proper feedback, even if it's just to clarify why they saw someone walking out on them (e.g., was the session description misleading?).

9. Fill out your evaluations

This is a great way to say thank you to your presenters and help make the conference better. Be sure to fill out the survey before the session ends and it's time to dash out to the next session. If the session is timed well, the right time to evaluate will be just as the presentation moves into Q&A.

10. Use Twitter to keep up on current happenings

FileMaker's official hashtag is #FileMakerDevCon. You'll see people sharing cool ideas, sparking informal sessions and announcing meetups at local restaurants. You can even use DevCon2Go to track Twitter hashtags. Jump in and join the conversation, and tweet what you learn. When the conference is done and everyone has gone home, Twitter will still be there connecting you!

11. Exhibitors are your friends

Let's be honest, exhibitors are trying to make money ... naturally. But you'll find that many of their products are designed to solve your problems. And almost all of them are at DevCon because they love FileMaker and its community. So find someone that could help you and strike up a conversation. @HOnza24U has some great tips below for how to get the most out of exhibitors.

Our beez would love to see you at the Beezwax booth. You might be interested to see what's cooking in the next release of Inspector.

---

There you go. Hopefully we'll see you at the Beezwax booth at DevCon. As always, drop a line in the comments (or via Twitter), especially if you have a tip of your own.

See you at DevCon!

- @BeezwaxTeam

Managing Files with AppleScript

2011-07-10T15:19:24Z

If you're like most power FileMaker users, you've discovered that it's a great tool for managing collections of things or for gathering disparate data sources for reporting. So you've probably wanted at some point to do one or more of these actions:

Get a list of files on your computer
Import a batch of files
Move files on your computer
Read the text of a file that doesn't import correctly (e.g., HTML)

Does that sound familiar? Unfortunately, FileMaker provides limited functionality for these operations. Here's a few handy custom functions for you Mac OS users to help you access the power of interacting with files on your computer. Each generates AppleScript that you can then run from a script using the Perform AppleScript command. Here are the core functions included:

AppleScriptDirPath
AppleScriptFilePaths
AppleScriptFilePathsInDir
AppleScriptMoveFiles
AppleScriptReadFile

Each function presents the user with an OS-native dialog and returns a list of paths to the files selected or moved. No plug-ins required!

Yes, this is another Mac-only demo (sorry Windows users!). But that's only because this technique arose out of a Mac-only situation. You could do something similar on Windows using the Send Event script step. You Windows users out there are more than welcome to post your versions of the functions. We'd love to make the demo cross-platform compatible.

FileMaker Pro users, don't despair. You can use these functions too. Each command shows you the AppleScript that it runs. So just copy and repurpose that text to have a fully functional AppleScript that you can paste into your scripts.

Have you done something similar or tweaked these functions for other purposes? Tell us about it in the comments!

Download demo file

Demo History:
Nov 11, 2011: added function for reading file contents; now accepts multiple resuts from AppleScript
Aug 12, 2011: enhanced error handling and function readability; moving files now returns list of destination paths
Feb 20, 2012: fixed bug with copying moved files; added support for FileMaker Pro; enhanced handling of files with "." in their name

Does your FileMaker Go offline? (Previewing the new GoZync framework)

2011-06-24T18:30:04Z

Some of us on the Beezwax team had the pleasure of watching John Sindelar and Todd Geist present their new GoZync framework at June's DIGFM developer meetup. If you know anything about either of these fellows, you know that they are both very sharp and visionary developers. Now they've thrown their collective brain power at the problem of "How do mobile users work with their databases offline?" The GoZync framework is designed to answer this question for FileMaker Go users on iPad and iPhone. For developers, it's potentially a way to face the challenges of syncing and connectivity.

The presenters and audience at DIGFM had an easy time providing examples of "offline database users":

Plumber working onsite at client offices
Legal clerk working in a secure (Internet-free) courtroom
Equipment-delivery driver
Education tutors visiting students
Survey-taker visiting villages in Africa

And the list goes on. Even an office worker walking between WiFi connectivity points, or starting and stopping FileMaker Go might face the "offline" issue.

For those of you who missed out on John and Todd's "GoZync Demo Tour", here's a quick recap:

Solving The Mobile "Offline" Problem

In a nutshell, GoZync provides a framework for transactional transfer of data between FileMaker Go apps and your server. This solves a host of problems that otherwise make deployment to mobile devices unfeasible or unprofitable on FileMaker Go. Instead of worrying about clients losing their internet connection, GoZync enables them to work offline and push their data to the server later.

Have the challenges of offline database use limited your deployment of mobile solutions (via FileMaker Go) for your company or a client? GoZync promises to change that.

How It Works

The common GoZync deployment will involve at least three FileMaker files:

Central hosted database, typically FileMaker Server
Mobile front-end deployed with FileMaker Go*
Intermediary hosted database containing core of GoZync logic

This is all FileMaker-native stuff. "No plug-ins required". To be clear, we're not talking about two-way syncing. (Really, that's super difficult to accomplish!) GoZync is a push-pull framework. It moves data between your mobile device running FileMaker Go and your central hosted database. It's up to a FileMaker developer to merge incoming data beyond the basic "last commit wins". But there's nothing stopping you from customizing the process.

* FileMaker Go supports iPad, iPhone, and iPod touch. But in theory the GoZync approach works with FileMaker Pro on a laptop, with the same benefits for offline database use.

What GoZync Does

Here's a rundown on some of the primary challenges addressed by GoZync:

Makes transaction as fast and reliable as possible

The biggest challenge with deploying hosted solutions to mobile devices is ensuring that data isn't getting lost or corrupted when the user quits their app or loses their connection. In GoZync, each set of records (parent and children) being pushed is sent as a single document to ensure that you never have orphans. Either the entire document gets transferred or the entire set of records is saved for transferring later. This "GoZync document" has a custom markup to ensure that it is also lightweight, readable and easily parsed in FileMaker. (Don't worry, container field data is also supported.)

Makes mapping of data between mobile and server files easy

Your success with a framework or extension like GoZync depends largely on how easily you can set up and configure it. Todd and John have made setup super easy in GoZync. Here's a rough run-through of configuring the push process (as I understand it from the presentation):

Open your GoZync file and add your hosted database as an external data source
Go to a configuration layout
Add a tab for your table and drop your desired fields onto the tab
- Data from each field will be posted to a variable named after the field
Export and open customized setup instructions (yes, customized!)
Add some Set Field steps to map the data variables to the receiving file

The data parsing and mapping is all unlocked so you can customize it easily. You have room to add your custom data validation or syncing logic if you wish. GoZync also includes some robust error handling to ensure you get the variable names right.

Keeps dependencies to a minimum

Using an intermediary file means that GoZync can be bolted onto an existing solution with very few modifications to the existing files. You don't even need to create accounts for the mobile users because they only interact with the intermediary file. There aren't even any plug-ins involved.

Handles smooth delivery of new mobile files

I missed some of the nuances here, but the bottom line is that developers can release new mobile databases with minimal hassle for all involved. Users click a button, get a database version update, and land back on the same layout when they're done — new file, data set preserved, no fuss. End users never have to worry about finding the new file or determining which file is current. You can also deliver new — even customized — data sets with your updates if you choose.

What does this mean for FileMaker and your business?

Mobile is a not just about new devices, but potentially about new markets for FileMaker. Mobile users offer FileMaker developers an opportunity to build new types of solutions.

John expressed it well in his presentation. And you may hear him say it again, because it's an important point (paraphrased here):

FileMaker has worked well for us in office settings. If we've looked to help a business, it's been in the office where we're used to working. We never thought to look at the delivery trucks in the parking lot. Now we have a high ROI product to sell to all those trucks!

GoZync isn't the Holy Grail to solve all syncing and connectivity problems, but it does provide an elegant means of storing and sending data. Now every time I see a clipboard, I can envision replacing it with an iPad with a FileMaker Go and GoZync integration running on it.

Unleashing Mac OS X's Color Picker in FileMaker

2011-03-21T02:01:46Z

Color is one of the most important tools available to you when designing user interfaces. Using a little color can turn a drab wall of text into something attractive and readable.

The human eye is tuned to perceive color. This makes it a key tool for helping users quickly sort through complex information. This isn't to say that your layout should be a tacky rainbow of hues. All it takes is a little deliberate and tasteful formatting here and there to increase usability for your users. This post presents a technique that allows users on Mac OS (sorry Windows users!) to harness the power of color by unleashing the Color Picker in their solution. It's pretty simple really; all you need is a global field and one custom function!

Color to the rescue

Color helped with a recent FIleMaker system we built for a client to handle project management. The users were very visually-oriented, but they also had a good deal of complex data to sort through. They were viewing multiple projects, each of which were progressing through various stages. Our challenge was to reduce the apparent complexity of this data so that someone could find what they were looking for at a glance.

Color is a great way to help users identify groups and trends. Since configurations were going to be ever changing and growing in this database, we decided to let the users choose the colors. Herein lies the problem: In FileMaker, how do you allow users to dynamically select and view colors of layout elements?

Dynamic Color Assignment in FileMaker Pro

FileMaker is very limited in the area of dynamic color assignment. The only way to dynamically set a color, outside of the Web Viewer, is to color text via the TextColor() function; otherwise, you are stuck hard-coding the color. With layout objects, your closest option is to use conditional formatting. This is useful, but the only way to account for multiple possibilities is to code conditions for them upfront.

Allowing the user to set a color is also tricky. Who wants to type in a RGB value? You could alternatively paste in some colored text and extract a color from there (hint: use the GetAsCSS function), but that isn't much easier.

The Mac OS X Color Picker

We were fortunate in that this client is exclusively using Mac OS X. One of the great things about working with Apple’s desktop OS is the availability of system resources for FileMaker to call via AppleScript. You can access these from FileMaker using the Perform AppleScript script step. In our case, the golden resource is AppleScript's "Choose Color" command, which presents Mac OS X's default Color Picker and returns the user’s selection. The Color Picker is plenty robust for our needs, so all we need to do is parse the results and send them back to FileMaker.

Some other features of the Mac OS X color picker worth noting:

Multiple slider options (Grayscale, RGB, CMYK, HSB)
Color wheel
Eye dropper (looks like a magnifying glass)
Configurable palettes (they can even be transferred as files)
Extensible (you can download and install free plug-ins)

You can also find quick Color Picker guides, like this one.

Using Mac OS X's Color Picker in FileMaker

The technique presented here will give you (on Mac OS X) a polished and robust Color Picker with no requirements other than a custom function and a global field. You can even set the default color displayed on the Color Picker. Here's how:

First, create a script that does the following:

Generate AppleScript using a custom function
- This function allows you to specify the default color and which global field will receive the result:
  
  AppleScriptChooseColor ( fullFieldName ; defaultColor )
  
  The following calculation will open a Color Picker defaulting to red and return the user’s selection in the field FOCUS::TEMP_TEXT_GT.
  
  AppleScriptChooseColor ( GetFieldName ( FOCUS::TEMP_TEXT_GT ) ; "RGB ( 255 ; 0 ; 0 )" )
Retrieve the resulting RGB() statement from the global field
Store RGB statement or value wherever it is appropriate
- You can use a field in the database record being colored
Use the RGB value within a TextColor() statement

Pretty simple, right? What you do with the result is up to you.

In the attached demo, I used Webdings (available by default on Mac and Windows) to format a square text object with the color. Check it out and let me know what you think.

Download the demo

Demo updated Nov 16, 2011. Enhanced error handling and AppleScript compatibility. Note, this demo may not be compatible with versions of FileMaker Pro prior to version 11.

Beezwax Team Completes Speed-Developer Challenge at DIG-FM

2011-04-29T21:27:50Z

Can you build an Assets Management database in FileMaker Pro in 80 minutes?

Thursday night we completed that challenge!

DIG-FM Speed-Developer Challenge

Team Beezwax (Vincenzo Menanno, Rennie Innis, Robert Ward and Jay Gonzales) were at DIG-FM last night, and entered the Speed-Developer Challenge. Here was the task:

Your mission, should you decide to accept it, would be to create a database that tracks University departmental assets like computers, laptops, monitors, and any office equipment of value. They would also like to be able to look up employees and quickly see what assets those employees have checked out or have been assigned to them ... and it would be great if the customer could track the history of asset assignments and locations, and an employee's equipment history ... and asset detail should include a place to put pictures of assets, and employee detail should have a place to put pictures of employees ... and you have 80 minutes...and there is no talking because you are working while the meeting presenter is presenting...etc.

The "no talking" rule made things very interesting. Most of the collaboration was using iChat, pen + paper, and vigorous finger pointing at laptop screens. We worked together on the database via a remote FileMaker Server, too.

While we worked, Eric Matthews demonstrated some solutions he's built at San Jose State, and how FileMaker has enabled University departments to quickly implement some complex solutions for ID card readers, document management, et. al.

And The Winner Is...

We completed the Speed-Developer Challenge! Our resulting database was not quite feature complete (no picture support), but it was the only solution that was uploaded to the Challenge server, looking functional. Just give us another 10 minutes and I'll bet we could have had SuperContainer implemented for photos!

The prize (courtesy of FileMaker, Inc.) was a copy of FileMaker Advanced, which was donated back to DIG-FM as a raffle prize for the meeting.

Here is a picture of Vince getting up to present the winning solution, which was also a nice moment to mention the Beezwax FOCUS toolkit as the starting point for our solution.

And, finally, here is a time-lapse screen capture of Vince's screen (courtesy of the Mac application ScreenNinja) during the challenge. 80 minutes of an intense multi-developer FileMaker project collapsed to 90 seconds. Enjoy!

FileMaker Instant Web Publishing, Part II: Five Top Tips for Success

2011-03-21T22:19:24Z

Part I of this series introduced Instant Web Publishing (IWP) as an alternative to the traditional client-server deployment (FileMaker Server to FileMaker Pro). We noted that it is very easy to get started with IWP, and also very easy to get hung up on its limitations. But you can use IWP successfully if you learn to work within its constraints. Here are my top 5 tips for successfully implementing IWP:

1. Use minimalistic layouts

It is almost certain that you will need separate versions of your layouts for IWP. These should have straight lines, no extraneous graphics, and white backgrounds. The white background is helpful to help reduce the impact of the white flash your browser is going to give you every time the screen redraws (which will be often). Screen redraws are also distracting when the user doesn't expect them to occur. Tabs are are a primary culprit of this, so they are best avoided in IWP.

I have found the workflow to be much smoother on IWP when using simpler, more narrow-purpose layouts that render once. This way a redraw only occurs when the user is specifically requesting (and expecting) a transition.

The following images (taken from rough prototypes) illustrate the difference between a more typical FileMaker multi-purpose layout (top) and a minimalistic single-purpose layout (bottom).

Multi-purpose layout. Designed for FileMaker Pro client.

Single-purpose layouts in FileMaker Pro. Optimized for Instant Web Publishing.

2. Create a transactional interaction model

One aspect of IWP that users may find confusing is managing the record state, i.e. whether record data has been committed to the actual database. FileMaker Pro makes this a non-issue, but IWP users must explicitly open and close records using the "Edit" and "Submit" buttons in the status area. This is likely going to be inconvenient and unfamiliar to most users.

A polished solution will not require its users to view the IWP status area or to learn how it works. The most polished option is to remove the status area altogether, but that requires you to script all the functionality you just hid from your user! You may not want to go that far, but you should at the very least relieve your users of worrying about the state of a record being edited.

This doesn’t mean you need to have a giant “Commit” button on every layout, but you will need to have some explicit action that the user understands must be done before their data is saved. Narrowly-focused layouts, as mentioned above, can help with this because each layout transition is an opportunity to clearly indicate a change to your users. For example, you could have a layout that each user only sees when entering data, thus indicating to the user that a record is not committed.

3. Check for incompatible script steps

This is important, because IWP gives you almost no feedback here. By default, IWP will abort a script when it encounters an incompatible script step. Once you set the Allow User Abort script step to "Off", the script will skip right over incompatible steps. This doesn't solve your problems, however, because your script might be missing something important when it skips that incompatible script step. And, if those scripts are being run in FileMaker Pro, it’s risky to have your errors suppressed automatically; it could be hiding important problems from you. My best recommendation is to include a subscript at the opening of each relevant script that will turn Allow User Abort off only if it is being run in IWP.

4. Include a "Log out" button

Logging out is another functionality that is provided by the status area but will be pesky for your users to learn. If you don’t provide an explicit and prominent way for the user to log out, his or her session will persist after they close the browser window. This could cause you unnecessary performance and security concerns.

5. Test early!

Each web browser will render your layouts differently, so be sure you try them out as early as possible in the design process. This could save you much heartache later on! For example, you may not expect that your scroll position is reset when you enter a record in list view (it will be!). You may also be surprised after switching to portals that they don’t work in Safari on iOS!

Another important aspect to testing is performance. If you expect to have 5 users online at a time, be sure to test with 5 concurrent users so you know how responsive the system will be.

Conclusion

There are other tricks you can use to master IWP, but following these guidelines should get you started off on the right foot. Or maybe you have some tips of your own we didn't cover? We'd love to hear them in the Comments.

Other Resources

FileMaker IWP Overview (includes comparison with FileMaker Pro, links to related knowledge base articles)

FileMaker 11 IWP Guide (official white paper, contains implementation details)

FileMaker Professional Training Series (helpful for comparing web publishing options)

FileMaker Instant Web Publishing, Part I: Is IWP Right For You?

2011-03-19T20:07:33Z

FileMaker's Instant Web Publishing, a.k.a. "IWP", essentially converts your FileMaker layouts into basic web pages and forms. Yes, your FileMaker database could be accessible through a web browser!

This post is the first in a two-part series designed tol guide you through the process of choosing and implementing FileMaker Instant Web Publishing. Here, in Part I, I'll cover why and when to consider using IWP. Stay tuned for Part II, which will dig deeper into IWP implementation.

FileMaker on The Web: Beyond Traditional Deployment

For workgroup database users, traditional FileMaker deployment is "client-server". In this setup, each user in a workgroup uses a FileMaker Pro client to connect to FileMaker Server, which hosts the database files. You get FileMaker's desktop interface, with the full functionality of layout objects, scripts, etc.

However, there are situations where this traditional deployment may not be the best solution. Here are some of those cases:

Not every user has FileMaker Pro software (e.g. users outside your organization)
Users are far away (e.g. overseas), causing slow connection speeds
Users have limited bandwidth (again, causing slow connection speeds.)
Users are accessing via mobile device

Web deployment is one of the primary options for these situations because it allows you to view your database through a web browser instead of the FileMaker client. Web browsers are great because they are now ubiquitous and can be very efficient at transferring data.

[Note, web browsers are not the only option. Some notable alternatives include terminal services, FileMaker Go, or even an "offline" client that syncs data with the server. But these are also topics for another day.]

Common Web-Based Interfaces To FileMaker

FileMaker provides several options for web deployment:

Static Web Pages
- Save FileMaker records as HTML pages, then host them from the FileMaker Server web folder, or on another web server
Instant Web Publishing
- Provides interaction with FileMaker Server* though static web pages and simple forms generated by FileMaker Pro
Custom Web Publishing
- Serves data to dynamic web pages via XSLT (being deprecated) or PHP
- FileMaker 11 provides a Site Assistant for both XSLT and PHP to help you generate your pages
Using FileMaker as an ODBC data source
Using FileMaker as an XML data source

You can view FileMaker's documentation on these options here.

* IWP also works from a single-user copy of FileMaker Pro. Serving your database this way really limits your use of the database, so this article will focus on Server-based solutions.

Instant Web Publishing

Instant Web Publishing is often touted as a “plug-and-go” option of database publishing. In fact, IWP can be turned on with just a few clicks. This ease of deployment is its primary strength.

But with IWP's ease comes several caveats. It doesn't give you fully interactive web pages like you may expect; we're talking about static pages and forms. Your layouts will also need considerable tweaking before you can achieve any polish and ease of use in IWP.

Be aware of the following benefits, costs, limitations and considerations before committing to an IWP deployment.

Benefits

FileMaker Pro clients may not be cost-effective or responsive enough when used by users who are distributed geographically. This is especially true over long distances, and when users only need occasional access. Offering users access to your database via Instant Web Publishing allows you to reach more people without the overhead of purchasing dozens of FileMaker clients.

Instant Web Publishing also helps you speed up the user experience by limiting the amount of data that needs to be transferred between the user and your server. IWP is particularly beneficial over other web deployment options in that it gives you all this functionality at a fraction of the price of building a web front-end by scratch.

Costs

The primary cost for IWP is the development required to achieve your expected level of polish and usability. While this will likely be less than the cost of a full-scale web development project, it is not negligible. You can easily see the limitations of IWP by enabling IWP in one of your databases.** The first thing you'll notice is probably that the layouts don't look quite the same. Accomodating these limitations involves work in the following areas:

Heavily customized layouts (to accomodate different page renderings in IWP)
Rebuilding UI flow (to work around page refreshes)
Modified scripts (to address steps incompatible with IWP)
New scripts (e.g. to support status area functionality)

Instant Web Publishing via server also requires FileMaker Server Advanced (as opposed to FileMaker Server). This is not a negligible cost.

** See FileMaker's Instant Web Publishing Guide for information on how to enable IWP

Limitations

Some limitations of Instant Web Publishing:

Performance degradation for multiple users
- You may notice the system become less responsive with even a couple of simultaneous users.
Fewer UI options
Minimal or clunky workflows
Requires FileMaker Server Advanced
- Yes, as previously noted, IWP requires FileMaker Server Advanced for server deployment; it won't run with plain-old FileMaker Server.
Requires Internet Information Services (IIS) to be installed when deployed on Windows

Considerations

Getting a FileMaker database to appear as functional, well-polished web pages requires some effort. Web pages served through IWP do not behave like a FileMaker Pro client in many respects. FileMaker's documentation emphasizes the ease of IWP and provides some tips on implementation, but leaves the reader to infer many of the considerations.

Here are some of the challenges you will want to be familiar with before attempting the IWP option. This is not to criticize FileMaker or IWP; think of it rather as a friendly list of cautions.

Pages will be static
- The entire layout will need to be redrawn pretty much any time the user clicks on something or when first entering a field on the page.
Fields and text objects do not look the same in IWP as in FileMaker Pro (client)
- Drop-down menus are treated as pop-up menus (which, honestly, I think are ugly).
- Field sizes will differ from FileMaker. They will likely need to be bigger.
- Appearance and behavior of pages on an iOS device are especially different from the desktop browser.
Conditional formatting does not work
- This will negate the handy portal row highlighting technique many of us use today.
Buttons cannot be placed beneath other layout objects
- This means that those buttons you like to place on a portal row will need to be above the fields or include the fields, which can be a real pain.
Record commits are handled differently
- Any data entry (even when filtering) requires the user to (whether manually or via script) enter “Edit Mode”, then explicitly commit their changes when finished. Clicking outside a field does not commit the record.
You may want to hide the Status Area
- IWP produces a Status Area (much like in FileMaker Pro) at the top of the web page, which might not match your desired aesthetic.
- Removing the Status Area requires you to script all of the functionality for the user.
Rendering is very limited
- Curved shapes and angled lines do not display properly.
- Icons will display differently. Transparency may be ignored.
- Sizing of objects is not 100% faithful to FileMaker layouts, primarily because of additional weight given to the borders of enterable fields.
- You'll get best results with very minimalistic layouts.
Some scripts steps are not compatible with IWP
- When IWP comes across an incompatible script step, it simply halts the script, unless Allow User Abort is set to OFF.
- Notable incompatible script steps include anything adjusting windows or exporting data: Freeze Window, Show Custom Dialog, Print, Enter Preview Mode, etc.
Single-window interfaces only
- New windows will appear to replace the current page.
Users need to log out
- User sessions will persist unless they press “Log Out” or a script runs the Exit Application step.
- This is an example of a Status Area feature that needs to be scripted if the Status Area is hidden.
- You may want to devise a process or button that ensures users log out successfully.

Below are some screenshots that compare the FileMaker and IWP renderings of a simple FileMaker layout. You will see some of the following considerations listed above in play: object transparency loss, rounded FileMaker objects become square, text looks different, conditional formatting lost, etc. Click on the image to see full-sized version.

Layout rendered in FileMaker (click to expand image)

Layout rendered in Safari via IWP (click to expand image)

This is in Edit Mode, which occurs when the user clicks to edit the record. I've added some comments to highlight the differences.

Tips

That's quite a list, but don’t let Instant Web Publishing scare you. It can still be a quick and cost-effective option when the use case is basic data entry or browsing simple lists of records. The layouts in FileMaker's starter solutions, for example, manage to render quite well in IWP. With some work you can support more complex database functionality, or at least account for how the IWP interface will affect how users interact with your FileMaker database.

Part II of this series will give you some useful tips to ensure you start your next IWP project on the right foot.

Inspector Pro 3.0v2 Adds FileMaker Server and FileMaker Go Support

2011-03-14T20:35:58Z

We just made available Inspector Pro 3.0v2, a new version of our tool for analyzing and debugging FileMaker databases. The new functionality in 3.0v2 includes support for FileMaker Server and FileMaker Go.

This update also fixes a few known issues, like digesting large FileMaker Database Design Reports (DDRs).

Here are details about the update:

FileMaker Go Support: Inspector Pro 3.0v2 files can be viewed on iPad using FileMaker Go. (An iPhone would work too, but an iPad is highly recommended for viewing Inspector Pro report layouts).
Support for FileMaker Server: The report files generated by Inspector Pro are, of course, FileMaker Pro databases. So, this new functionality allows these files to be hosted on FileMaker Server and accessed by multiple developers who each have a copy of Inspector Pro. It's perfect for the common scenario of a team of developers working on optimizing a large & complex database.
A fix to allow very large DDR files to be processed. We're using code libraries for parsing XML that are optimized specifically for each platform: Mac or Windows.

If you already own Inspector Pro 3.0 or 3.0v1, you can use the Download/Demo page to get the update.

If you want to know more about Inspector Pro 3, here's the product page to get you started with info, or a demo.

For a comprehensive list of additions and fixes in Inspector Pro 3.0v2, check out the Wiki.

FileMaker UX for Developers at PauseOnError

2011-03-14T08:41:34Z

At PauseOnError, Vincenzo Menanno led the session on FileMaker User Experience (UX) for Developers, brainstorming how to improve the tools we use as FileMaker developers. There were a couple dozen participants, including Heather Winkle, Product Manager for User Experience at FileMaker Inc.

The slides from this presentation are available on the PauseOnError Wiki. Vincenzo shared these notes summarizing the session:

"I tried to frame the FileMaker UX discussion with this notion of little things make a big difference. Two key aspect to any UI -- for end users or developers -- are the notions of finesse and refinement. These links to UX/UI resources and examples were provided to get people inspired:

Little Big Details

John Underkoffler @ TED -- on the future of UI (around the 8:00 minute mark is 30 second clip that was shown)

Huge Infographics Design Resources

The effort to inspire worked, because there were a number of great requests and suggestions which I captured...

More data visualization tools for developers.
A filtered Relationship Graph where you can locate a table occurence by selecting it in a filter (Courtesy of Bruce Robertson).
Mini-graphs attached to layouts to show relationships.
A calculation dialog with a splitter, to be able to see a wider list of functions.
Security perspectives, such as a way to select a privilege and see what kinds of permissions each field has -- without having to dive 4 levels deep into security dialog
Enhancing ScriptMaker as a development environment:
- Code folding
- Gray out disabled steps
- Color code certain steps
- Find things like variables (anybody remember the tool mentioned that does this?)
- Calculated break points
- Security perspective in ScriptMaker
- Write scripts instead of clicking
Layout development
Ways to deal with multitouch environments.
Transparent layouts - and a way to build augmented reality systems

There were many other great ideas -- Script Debugging improvements, color coding and formatting, et. al.. We only scratched the surface of FileMaker UX possibilities. I encourage developers to spread the discussion, and continue with these ideas on the PauseOnError discussion board and other places where we can discuss FileMaker UX for developers. –Vincenzo"

PauseOnError - the FileMaker developer "Unconference"

2011-03-08T00:42:00Z

In February, four Beez traveled to New York for PauseOnError, the annual winter gathering of FileMaker developers. PauseOnError runs as an "Unconference"; attendees organize the entire agenda, and work together to support presentations and ad-hoc discussions. This makes for a highly-relevant and participatory experience.

In the third year of PauseOnError, we saw the deepest range of discussion topics related to FileMaker development and consulting: agile, data modeling, testing, FileMaker Go, User Experience, recruiting, business marketing, the FOCUS framework, Web and SQL integration, and more.

Fortunately, there were plenty of the best, brightest and most generous FileMaker experts in attendance. Participants shared their time and tips, not only with other attendees, but also with the world – via Twitter, reports to FM User Groups, blog posts, the conference Wiki and other channels.

PauseOnError has turned into a much needed late-winter opportunity to connect with our peers in the FileMaker developer community. Our biggest industry conference, FileMaker DevCon, is always in late summer. Yet, as fast as technology moves, a year between major meetings with the FileMaker world would otherwise be an eternity without PauseOnError.

This year's PauseOnError event even "sold out" – or rather, "ran out of space" since it's a free event. That kind of crowd is a healthy sign for the FileMaker community. The biggest challenge might be accommodating the growth of interest in such a gathering.

Finally, even though PauseOnError is attendee-driven, there is a steering committee that worked hard to bring everyone together. Here's a big "Thank You" to Molly Connolly, Ernest Koe, Andy Gaunt and John Sindelar. Can't wait until next year's event!

Charting from the Active Field

2011-02-25T20:43:18Z

Neither I nor my client can anticipate every chart that the solution's users might want to see. A user's desire to view a high-level visual representation of their data can be spontaneous and idiosyncratic. This technique allows for the user to create an ad hoc chart, albeit within narrow parameters (i.e. the chart is simple, presents only counts of values, and is pre-formatted).

Movie (click to download)

FileMaker File (click to download)

Components

Summary field. Each table needs a field called TABLE::SUMMARY to allow its data to be summarized.
Chart object. Displaying delimited data from global variables.
Script. Sorts the found set by the active field, then gathers counts of the records in each sub-summarized group. By using the GetSummary function, we avoid needing sub-summarized parts on the layout. (Credit to Bob Bowers of Soliant Consulting for bringing this summary-gathering technique to my attention.)

Gotchas

Mac OS only. Uses an AppleScript to sort the records. Because we're leveraging the active field, we have built-in assurance that the sort field is on the layout.
The script assumes the summary field is called SUMMARY.
As is, the script only supports charting a field whose table occurrence matches that of the layout's context. The script must be enhanced to support charting data from a related field (and there would be further behavior considerations).
Multiple instances of the chart, charting different data, cannot be viewed simultaneously. Running the script on a new field will stomp the values visible in any open chart.
As the found count increases, the sort requires more time to execute. With 1,000,000 records on a local file, the sort requires 32.7 microseconds to complete.

Area Disclosure in FileMaker Using Sub-Summary Parts

2011-02-25T18:57:42Z

The attached file demonstrates a technique for opening/closing areas of a record, allowing a user to hide the information they don't want to see.

Movie (click to download)

FileMaker File (click to download)

Key Components:

Sub-summary parts. This is the essential ingredient. FileMaker conditionally shows and hides these parts depending on the current sort criteria, doing the heavy lifting for us.
Sort fields. Each sub-summary part must be sorted by a unique field. We don't really care what the value of the field is, so I've leveraged the spacer fields that we typically have hanging around anyway (to separate different types of fields in the field list). Renaming these with a number component helps make the button parameters more readable.
Sort script. FileMaker doesn't allow us to sort by indirection, which can make for a convoluted conditional branching statement to effect our desired sort. Luckily, on the Mac OS we can employ AppleScripting to build more dynamic sort statements.
Drag-and-drop. This technique has been evolving in the community since the introduction of script triggers. The nuance here is that we're dragging from one part to another, rather than from one record to another.

Gotchas:

Mac OS only, since the solution employs AppleScripting.
The sort fields must be on the layout for the AppleScript to work. I've stacked these together in the top-right corner of the layout.
The sub-summary parts need to either be all leading, or all trailing, otherwise the drag-and-drop won't work when dragging from leading to trailing, and vice versa.
Sub-summaries only work in List and Table views. Since what we really want is Form view, I've isolated a single record with the opening script, and displayed it in List view. A custom menu prevents the user from toggling views. The next step (not present in this solution) would be to override the record navigation, allowing the user to quickly hop from record to record, but without having more than one record in the found set.
I've used Substitute as my function of choice to quickly swap field names in and out of the list of sort fields. This means the field names cannot be pattern matches of each other (e.g. MY_FIELD_1 and MY_FIELD_11 would pose a problem). My leading and trailing underscores in the field name solves this issue.
The drag-and-drop container sits behind the disclosure buttons. If the user clicks on the container and then tries to click the overlaying disclosure button, nothing will happen. An OnTimer script helps to ensure that the user's cursor doesn't linger in the enterable container field.
Custom functions are great! Much of the utility functionality has been abstracted into custom functions, such as the parameter passing (courtesy of SixFriedRice), so be careful when you copy and paste elements, as you'll need to copy the functions first.

Port forward for a Cisco ASA using ASDM

2011-02-04T01:35:36Z

I wanted to quickly create a firewall port forward (AKA NAT rule) for the Terminal Services port on a Cisco ASA 5505. Since it had initially been setup using ASDM, it seemed natural to also create the port forward this way.

Unfortunately, my first few attempts didn't work. Some searching only turned up examples using an older method that no longer works with newer software. In the end, I think the mistake I was making was in the very first step -- the originating interface should be inside, not the outside interface. Here's the exact steps I took to create this.

Create NAT Rule

Click Configuration (top)
Click Firewall (bottom-left)
Click NAT Rules (middle-left)
Select Add->Static NAT Rule
Original
- Interface: inside
- Source: 192.168.0.99
Translated
- Interface: Outside
- Select Use Interface IP Address
Port Address Translation (PAT)
- Check Enable Port Address Translation (PAT)
- Protocol: TCP
- Original Port: 3389
- Translated Port: 3389
Click OK

Create Access Rule

Click Access Rules
Select Add->Add Access Rule
- Interface: outside
- Action: Permit
- Source: any
- Destination: 111.111.111.111 <- the address of your WAN interface
- Service: tcp/3389
- Enable Logging: unchecked

the beezwax buzz : the beezwax buzz | beezwax.net

Native Web 2.0 Controls in FileMaker 12 Layouts

HTML5, jQuery, MooTools, ExtJS and more

A Sneak Preview

Web Viewers that Talk Back

Setting Up a Demo Project

Choosing from a Vast Menu

Setting Up the Basics

This is Ground Control to Major Tom…

…This is Major Tom to Ground Control

Houston, We Have Contact!

Giving our Web Slider some Style

Completing the Picture

Where to Go from Here

FileMaker 12: Exciting New Possibilities

First, Some Thoughtful Consideration

Now, The Exciting New Possibilities

A Better Foundation: FileMaker Server 12

More Speed? Yes, Please!

FileMaker Now Understands SQL Queries

Making Your Media Safe and Accessible

In Style With CSS

More Charts, At Your Fingertips

Going Mobile Has Never Been Easier

The Bottom Line

Open a remote FileMaker file with AppleScript

Recipe for testing JDBC connection to FileMaker Server

99 Bottles of Beer Challenge

The Joy of Diversity

99 Bottles of Beer, the FileMaker Version

Working with Repeating Fields

Good Sir William's Heirs

Version 0.50 of bBox Now Available

FileMaker Read-only Fields: Lighter, Smarter, Friendlier.

The Candidates

Our text fields: Waiting for a technique to make them secure yet friendly.

Exit Stage Left

Calculated Proxy Fields

Web Viewers

Web Viewers: Tantalizing. But no formatting…

Script Triggers

A Single Proxy Field

The dreaded warning dialog. “Stop slapping my hands!”

Hey! You Got Chocolate in my Peanut Butter!

Integrated Proxy Field with Triggers: Bullet-proof, pixel perfect.

Web Viewer Redux

Improved Web Viewers: Lean, Elegant, OS-native.

So Who’s the Real Winner?

DevCon 2011 Recap - Design Goes Farther

Varied Approach, Broad Agreement

Design as Central

A Polarizing Issue?

All We Are Saying…

Redefining Design

FileMaker as a Craft

We Are Designers

The Road Ahead

Special thanks to Don Levan for kindly providing detailed speaker notes from the Panel of Design Enthusiasts session.

Inspired by Address Book - Part I: Hiding portal scroll bars

Got white space? Hiding the portal scroll bar...

The FileMaker Ninja's Toolbelt: TextMate Bundle

A Text Editor that supports FileMaker Pro?

Getting It For Yourself

11 Tips for #FileMakerDevCon '11

1. Bring a sweater

2. Don't expect to find any outlets in the conference rooms

3. Get a schedule

4. Tackle one or two big questions

5. Don't feel like you have to go to every session

6. Find out who the popular speakers are

7. Seek conversations

8. Embrace the Law of Two Feet

9. Fill out your evaluations

10. Use Twitter to keep up on current happenings

11. Exhibitors are your friends

Managing Files with AppleScript

Does your FileMaker Go offline? (Previewing the new GoZync framework)

Solving The Mobile "Offline" Problem

How It Works

What GoZync Does