Wouldn’t it be nice if whenever you need a parameter you could just ask for it by name? Lets say that you have a create order script and you want to pass the script the name, street and zip code of the customer. If you were stuck with just the regular old FileMaker functions there ain’t no way that’s happening. But after you are done with this post, you will be able to get the name of your customer with the simple function: `GetParameter( “customerName” )`.
Another day, another awesome new FileMaker 9 feature. Today’s special: so called *data URLs*. In a nutshell, you don’t need a web site to use web viewers anymore. Now they can easily (read: without crazy exports and obscene path hacks) show data pulled right from the FileMaker database itself. This is, like, *way* cooler than it sounds.
This question came up on [Macintouch](http://www.macintouch.com/readerreports/filemaker9/index.html):
>Can you import an ASCII (.txt) file into Filemaker Pro 9 that uses a dollar sign ($) as a field delimiter within a record? The file is too big to bring into Excel first (on the way to filemaker).
Unfortunately, FileMaker 9 does not change the supported import formats, and $ delimited is *not* on the list. On the bright side, there are several ways to deal with this sort of thing in FileMaker.
Script debugging has received an overhaul in FileMaker 9. FileMaker 8 launched a great feature with the data viewer but FileMaker 9 has made it an indispensable tool. Not to be outdone, the debugger also received some updates that make it a much more powerful tool. All in all, I’m sure you will be happy with your new debugging tools.
One of the most annoying parts of FileMaker development is when I look on my screen and see: *”Some Guy” is modifying these items. You cannot use these items until “Some Guy” is finished.* I am sure you know exactly what I am talking about… You need to make a couple of little tweaks to your not-quite-finished script and FileMaker gives you that annoying little pop-up. Fortunately, FileMaker has finally gotten rid of this productivity killing problem and added a couple other gems to ScriptMaker with their newest release, FileMaker Pro 9.
How many times have you wanted to produce a report that showed *two different* lists of records? Or a couple pages of summary information, then a list of raw data? Or a title page, then a few pages of charts, then one list of data, then a few more charts, then a second list? In FileMaker, reports are tied to layouts, and a layout is tied to just one table. Of course you can just print several reports one after the other, but that doesn’t help if you want to *email* the report as a PDF, or store it on the file server.
Luckily, you can do all this (and more) with the new Append to PDF feature in FileMaker 9. Once you see it in action, you’ll agree it is very useful.
One of the least talked about features of FileMaker 9 is a new calculation called `Self`. Although the primary purpose of this function is to facilitate the Conditional Formatting feature (which can perform calculations on such unnamed items as text objects and buttons), `Self` comes in handy in lots of common situations.
There comes a time in every FileMaker developer’s life when she needs to export a file *temporarily*. Maybe you’re exporting records only to import them right back in again later. Or perhaps your creating a PDF file that you *only* want to email to someone.
And with this need comes an eternal question: Where should you *put* it?
Finally, in FileMaker 9, we have an answer.
FileMaker Pro 9 has another awesome new feature: *Autoresize*. Now your layout elements can stretch their legs when you give them a bigger window. Auto-resize lets you tell FileMaker how different elements on the layout should stretch and move as the window is resized by the user. But it can be a little tough to understand exactly how it works. Here are three tips to help you take best advantage of this awesome new feature.
In the old days, we used to joke that FileMaker’s user interface tools were stuck in the 1970s. You could make a long list of things *every application in the world did* that were hard to do in your own FileMaker-based systems. In the last several years, though, FileMaker Inc. has knocked a lot of biggies off this list: Custom Menus, Tab Controls, modern-looking check boxes and radio buttons. Oh wait, scratch that last one.
Now we’re left to fuss about things that are a lot less significant. But one area of constant annoyance in my user interface work is disabled buttons. I got my first Mac in 1986, and way back then, if some button on the screen just didn’t apply, it was sensibly grayed out, giving the user a clear indication that it wasn’t worth clicking. But in FileMaker, if you put a button on a layout, it has just one look. Even if you-the-wise-developer know exactly when it shouldn’t be clicked, you have no simple way to tell your user. Or do you?