July 2000

Ten Commandments of FileMaker Pro
by Brian Dunning

digg this article | del.icio.us this article

Any of us who have created something in FileMaker have had our praises sung by our users at one time or another: it's hard to go wrong with something so elegant and easy to use. But be warned: as easy as it is to be exalted, it's just as easy to stumble and follow Lucifer down the pit to eternal torment.

In the public interest, I therefore present these Ten Commandments, which, if obeyed, will insure your eventual translation to a higher state:

1. Sendeth thee not emails to the wrong recipient by mistake.

I worked once with a developer, who, upon receipt of a particularly nasty and scathing email from an unhappy client, attempted to forward it to his supervisor with the following comment: "Listen to this (unprintable). Should we fire her fat (unprintable)?"

Please, please, whatever you do, learn the difference between the Reply and Forward buttons in Outlook. Learn to use them effectively. Learn not to click the wrong one, and don't reply an email such as this back to its author, which is exactly what happened. Score one for Lucifer.

2. Useth not the Set Crash Mode[On] command.

No, Virginia, there is no Set Crash Mode[On] command in FileMaker. But there always seem to be plenty of people around who think there is, usually FileMaker users who know nothing about Define Fields or ScriptMaker, and who firmly believe that their developer has, like Machiavelli, deliberately placed land mines throughout a solution to "maintain control over the users."

Sorry to disappoint, but there is no way a FileMaker developer can do anything to deliberately make a solution crash. If there was, I'd have found it years ago to maintain control over the users.

Sometimes elements in any file can become corrupted for no logical reason: be it a field, the appearance of a field on a layout, a box or a line on a layout, a script, or anything. And when FileMaker attempts to access or display such an element, a crash can often result. A frequent miscreant is a Windows video driver, which can be particularly annoyed by corruption. Fortunately, much the same way a bay leaf is often found growing alongside poison oak, nature provides a cure along with the disease. Upgrading Windows with the latest version of DirectX and then reselecting a generic video driver will frequently do the trick.

3. Includeth not fonts in thy solution not present on the client's machine.

Remember the shareware developer who distributed a bar coding solution which relied on a commercial barcode font which his computer's prior owner had bought and installed. The shareware developer thought the font was built into the OS and sold his solution to dozens of unsuspecting customers. Think different.

4. Watcheth thy field length when developing on Mac for deployment on Windows.

Imagine a room full of students taking their final exam: for some, a test which will determine their future; for all, a stressful trial demanding the highest attention and effort. At least it's multiple choice.

It's even in FileMaker. A room full of Windows computers, with four available radio buttons for each question. Strange, about twenty percent of the questions don't seem to have the right choice onscreen. Oh well, better select the next best alternative.

The result? Nobody scores better than eighty percent, and the guy giving the test springs to his feet in the middle of the session, shouts an oath, and hurls himself through the glass window to his death several stories below.

And on his Macintosh Powerbook's screen, the same test: only, with Mac's smaller font metrics, all five choices are visible for each question. Cross platform developers are encouraged to test on both platforms.

5. Includeth not thy private comments on thy invoices.

Or, differently stated, give better, more descriptive field names to your Public Notes and Private Notes fields in your invoices file. So when your partner creates your invoice layout for you, it's certain that he'll put the right one on the layout. Imagine the private notes you might scribble to yourself to describe a customer who does not pay, pays late, complains, and inspires adjectives. Imagine his reaction when he sees these private notes mailed to him on an invoice wanting more money. Imagine you'll ever see the money? Keep imagining.

6. Testeth thy solution with the same printer used by thy client.

Those who fail to follow this simple commandment will find that their client's printouts don't quite fit on the page, or that their envelopes print upside down, sideways, or both. I know of three separate cases when an onsite troubleshooting visit was necessary, in all cases costing the client more than it would have cost to buy another copy of the same printer for the developer to test on.

7. Relyeth not on plug-ins which thy client hath not.

With a little elbow grease and some clever FileMaker work, you can get FileMaker to do most things that plug-ins provide, such as charting, filling foreign key date fields with date ranges, encryption, credit card validation, and so forth. However, someone already went to the trouble of creating these functions in plug-ins, and with some exceptions, the plug-ins are often easier to use than the 100% Pure FileMaker workarounds. By all means, use plug-ins whenever they make sense.

Just keep one thing in mind: solutions which rely on plug-ins only work on computers that have installed, paid for, and licensed the plug-in. Just because one guy in the office has plug-ins installed doesn't mean the solution will work for anyone else in the office.

In any solution which requires a plug-in, it's always wise to have your scripts test for the presence of the plug-in, and if it's not there, bring up a friendly dialog that explains exactly what needs to be installed, and how to go about installing it. And always be sure your users are aware of the site licensing requirements and the cost...BEFORE you charge them to put the plug-in into their solution.

8. Placeth not data entry fields on the header part.

Wouldn't it be cool if you could have a list view, with detail fields for the selected record in the header? A developer I know once went a step further: placing global fields for search criteria with a Find button in the header, and using the list view to display the results all on the same screen. It was a last minute brainstorm from a client who needed something quickly, and thought that one layout would be the fastest way to finish the solution.

Sounds great on paper. Not so great on screen.

In case you haven't figured out this Commandment yet, FileMaker does not let you enter fields which are in a header or footer (buttons inside portals in the header or footer don't work either). It seems stunning that this particular developer went ahead and delivered the solution as requested; perhaps his testing procedures were unusually lax that day, or perhaps he found that it was impossible to enter data into the search fields, but, since the client requested it, the client must have known a workaround. Wrong. Into the furnace with you.

9. Thou shalt not give thy developer a due date, then add specifications.

I am always reminded of the homeowner who hired a landscape architect, said "Here's my yard, can you have something nice done by this weekend?" And then, when the landscaper filled that bill, the homeowner came back, shook his head dubiously, and said, "No, I don't like that very much. Try something with more trees, and a different species of grass. By the way, since today's Saturday and I don't see that you'll have it done today, you don't get paid."

Or the motorist who dropped his car off at the "Fifteen minutes or it's free" speedy oil change shop, and asked "While you're in there, please drop in a new engine block, change out the wiring harness, and replace the chassis." Oh, it's not done in fifteen minutes? It's free.

10. Always givest thyself enough time to finish a project.

Oops.