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.
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?
One of the most exciting new features in FileMaker 9 is *Conditional Formatting*. I think this is awesome because now you can apply dynamic custom styles to layout elements without adding dozens of crufty unstored calcs to your table. When I first started playing with conditional formatting, though, I felt a little let down by one thing: There’s apparently no way to make something *disappear* using conditional formatting. I often have the need to show something to my user — an informational message, indicator icon, or even a button — only under certain conditions. It turns out that with some creative thinking, **you can show and hide layout elements with conditional formatting**. (Some restrictions apply.)