Converting to FileMaker 8

ScreenshotI’ve recently finished moving a client from FileMaker 7 to a runtime deployment of FileMaker 8. I took the opportunity to rework the solution, which still had much of the pre-7 design.

This took around three weeks, with two weeks I thought reasonable to charge for. I’m very pleased with the result, and my client understands the need for a good infrastructure behind the scenes.

Main Work of the Conversion

  • Moved all tables into a single file. The relationship graph for this leads to a much better overview of the system.
  • Implemented menus and deployed as runtime solution. Gives the feel of a true application, and hides unneeded commands from the user.
  • By using the recently added [new window] script set, the current found set is now maintained when running a report. This new capability also makes saving and restoring found sets behind-the-scenes unnecessary.
  • I also rebuilt the interface which had the same look as when the system was implemented 10 years ago. The tabs (pictured) are based on the anthrazite look in ‘Apple Mac OS X Appearence Template 1’ [sic] by Martin Brunner.


  • Start at the bottom and work up: copy tables which other tables depend on first. Ditto for scripts. Keep the names the same until everything’s across. Define as many relationships as possible early—it will save broken fields and scripts.
  • Use the developer’s version: FileMaker Pro 8 Advanced. Being able to copy & paste tables and script steps was invaluable. The Script Debugger and Data Viewer saves having to insert those [display dialog] statements too.
  • Most scripts need modifying: some will be broken from the copying process, others break because the context is different in a single file.
  • I’ve always adhered to the KISS principle, and was grateful for it on a number of occasions: don’t make elaborate workarounds to force FileMaker to behave as you want, instead accept its (sometimes quirky) behaviour. The less complexity, the easier the solution is to manage.
  • If I wasn’t deploying a runtime solution, every script would be in a single menu—for both me and the user. This would have made consolidation into a single file problematic.
  • Expand those dialog boxes! Most can be stretched, and it really helps to see more at once. e.g. when specifying the script for a [perform script], as every script for your application is now in a single file.
  • I wish I had two screens (each running their own version of FM), so the old & new could be displayed side-by-side. So I got to know the Database Design report instead.

Wish List

  • When creating a runtime, that you could create it for both platforms (Mac and Win), not just the platform FMA is being run on (for a workaround, see my blog entry).
  • That runtimes could create PDFs (instead I’m using the schubec PS2PDF Plug-in, which has excellent user support).
  • A way to copy a layout in its entirety. Redefining the sections, margins, etc., for each one got old very fast (and time consuming).
  • The inbuilt tabs are a great idea but too limited for most serious use. They need to be able to switch between list & form mode, and need to be scriptable. A vertical orientation would be useful, and a nicer look would help too.
  • In layout mode, an easier way to navigate the now very long layout menu. Maybe subfolders. Having the menu start at the current layout (per a pop-up menu) would also help.
  • Script logic indentation on the Database Design report.


Once again I’ve been very impressed with the reliability of FileMaker. I’ve been thrashing it for weeks and only had two glitches:
  • Occasionally there was a disconnect of some menu shortcuts: keyboard shortcuts (e.g. command-v) would flash the menu but otherwise be ignored. Restarting FM fixed this.
  • [if get(foundcount) > $var] was failing when there were 10 records in the found count and var was 9. Wrapping $var in asnumber() fixed it. Presumably FM was treating $var as character (‘1’ is not greater than ‘9’), but why is another matter—in a test file it worked fine.


Files131Some tables had already been consolidated into other files
Fields  Some saving with local variables replacing temporary globals
Layouts≈153≈120Savings from using [display custom dialog] instead of a layout, from files which were hidden from the user but needed navigation ‘just in case’, and some cleanup work
Scripts≈500≈200Scripts no longer need to call scripts in other files, they’re self-contained. No need for a set of navigation scripts in each file. Some combining of similar scripts and passing a parameter instead.


Homepage Visualisation

My homepage as a graphicI received a link to a very cool web visualisation tool by Sala (although I used the version by Markavian which enables you to click on a dot to see the source tag): this Java applet represents a web page and its elements as coloured dots.

It’s a quick way to get a feel for the kind of HTML used (tables, or divs, etc.), the complexity of the page, number of images, and more.

My home page is pictured:

The black dot is the root node.

Going up from there we have a grey dot for the <head>tag, which is the parent for many other grey dots—the <title> and <meta> tags, etc.

Going down is the grey dot for the <body>.

On the right we have a red dot for my main menu which is a <ul> tag, with a large cluster of pink dots for the individual <li> elements, and blue dots for their respective links. Note the other two small groups for the submenus.

Going (mostly) down from the root we have a green dot for a <div> tag, which encloses the footer (the two orange dots for <p>).

On the left we have a green dot for the <main> section, immediately surrounded by paragraphs (orange), one of which links to the cowboy picture (violet).

The left most orange dot is the paragraph containing the icons (violet) at the bottom of the page. Each icon is inside a link tag (blue).