If you thought FileMaker 9 was a big update ([and we clearly did][fm9]) you’ll be thrilled with number 10. It starts with some flagship new features like Script Triggers (_finally!_) and infinitely more useful Sub-Summary parts, plus the usual round of small tweaks and improvements. But this release takes it one step further with a total overhaul of FileMaker’s most ubiquitous interface element. Gone is the Status Area, replaced by a freshly designed, much more useful Status Toolbar. Here, we’ll introduce you to everything new in FileMaker 10. Keep an eye out for more articles about how to use all this great new stuff.
[fm9]: http://sixfriedrice.com/wp/category/filemaker-9-tips/ “Our Articles on FileMaker 9”
>Update Jan-5-2009: Somehow I neglected to cover the new Modify Table View feature in Filemaker 10. I have updated the article with relevant information, as it is quite important.
>Update Jan-6-2009: I corrected the explanation of the [`Code`][code] function, which was stupidly dismissed in the original text.
>Update Jan-15-2009: I’ve uploaded the live sub-summaries demo file by request. Get it here: [People.fp7][ssdemo].
[code]: #code
##Everything Old is New Again
Here’s what a basic FileMaker database window looked like yesterday (and in fact, it looked a lot like this when I started using FileMaker 15 years ago):
As of today, it looks like this:
As my mother would say…holy catfish. The most striking change, of course, is that the tools are on top now instead of along the side. This will almost certainly rub a lot of people the wrong way because carefully designed layouts that fit in perfectly sized windows on small screens will now be the wrong size and shape. After all, the maximum window size just got a little wider and a little shorter.
>Note: Of course, if you keep the status area hidden in your solution, your database windows are significantly smaller than the screen, or you make heavy use of [auto-resize][resize], then you won’t have to worry about the size change.
[resize]: http://sixfriedrice.com/wp/filemaker-9-tip3-get-the-most-from-autoresize/ “An article about FileMaker Pro 9’s auto-resize feature”
I hope the uproar over this annoyance doesn’t overwhelm the chorus of praise, though. After all, the new Status toolbar (it’s not called the Status Area anymore) beats the old version in several important ways:
* It does lots more. In the picture above, you can see buttons to manipulate the found set, perform finds, and bring up the sort dialog box. Switching between views (you know, Form, List, and Table) is now a quick click away, and the Edit Layout button makes quick work for mousers.
* Its horizontal configuration makes better use of space. Finally, the Layout pop-up menu is wide enough to show reasonable layout names. You can see the difference by comparing the layout pop-up menu in both pictures above. The new version is clearly much bigger.
* It is customizable. Your more adept users can now add buttons to the status toolbar for common FileMaker functions, move things around, switch between large and small icons, and so on. The changes they make will apply to every database they use, introducing a little consistency for folks who use several different databases.
* This is probably a matter of opinion, but to my eye, it is a lot prettier. And I like pretty things.
* Finally, it is more consistent with other applications, especially on Mac OS X. In fact, Mac OS X users will recognize this as a stock-standard toolbar that works just like other applications. And Windows users will still be comfortable with the more common buttons-across-the-top arrangement.
> Note: Before you get your hopes up, you should know that the status toolbar can be customized by the _user_, not by the _developer_. You can’t script the placement of buttons, add new buttons, or otherwise control how your users see things. They get to decide how their toolbar is arranged. Of course you can still hide the status toolbar, and keep it locked away from your users, so you haven’t _lost_ any control here.
A full discussion of the new status toolbar would require an entire article, so for now it will suffice to say it really represents a massive refinement and rethink of the way people interact with FileMaker, both as users and as developers.
It is not simply a cosmetic change. Instead, things have been reconsidered in intelligent, friendly ways. It makes common tasks easier to get to, and helps new users discover FileMaker’s features more naturally. On the thoughtful side, consider the black-ish layout bar which attaches itself under the status toolbar whenever you’re in layout mode:
It politely shows you the context of the current layout (right after “Table:”) which is important information, and was squirreled away in a dialog box in FileMaker 9. And its little pencil icon gives you one-click access to the Layout Setup dialog box.
One final staff favorite: In Browse mode, when you click the clever pie-chart representation of the found set, FileMaker runs the Records -> Show Omitted Only command. You can quickly click to swap the found set in and out, and the pie chart makes it clear what is happening.
New users will quickly discover the Edit Layout button when in Browse mode. In truth, it is simply another way to get to Layout mode, but it is presented here in a way that saves first-timer’s a trip to the online help. It switches to an Exit Layout button once you get to Layout mode, so getting back is just as easy and obvious.
Individually, these may seem like inconsequential things, but FileMaker 10 is full of subtle refinements like this, and all together, they really make for a more sensible, approachable, and convenient interface. Once you get used to using 10, you’ll find yourself missing the new arrangement whenever you switch back to 9.
> Note: Although the interface redesign is a significant positive step, I don’t want to over sell it. Visually, nothing has changed _inside_ the database window. Pop-up menus still look retro-80’s. Radio buttons still render funny on Windows. Checkboxes still look like something my 7 year old drew in KidPix. Alas, we get no shiny on our layouts in this release. Just a much better experience in the parts FileMaker controls directly.
##Loaded and Ready
Without a doubt, Filemaker 10’s most significant new feature is script triggers. This fabled hero has, over the years, gone by many names: events, triggers, actions, behaviors… Whatever you call it, here’s the scoop: In FileMaker 10, you can cook things up so scripts run automatically in response to various actions. For instance, imagine you want some scripted magic to happen whenever someone clicks to a certain tab in your tab control. In FileMaker 9, the intrepid developer would have to delve into [hidden tabs][hidden-tabs], masked buttons, and who knows what else to pull this off. After all, scripts run when people click buttons, so you have to trick the user into clicking a button when they really want to select a tab.
[hidden-tabs]: http://sixfriedrice.com/wp/tab-controls-without-the-tabs/ “An article about hidden tabs.”
Imagine you could turn that reasoning upside down, though. Instead of thinking about clicks, think about actions. As in: When the user switches tabs, run this script. That’s the gist of triggers. FileMaker runs your script in response to something. In this example, you can tell FileMaker to run your script when the tabs are _modified_—when someone changes which tab is selected.
Triggers are associated either with the layout (choose Layouts -> Layout Setup, then switch to the Script Triggers tab) or a single layout object (select the object, then choose Format -> Set Script Triggers). Some triggers even have the power to cancel the original action by exiting the script with a result of `False`. For instance, if a script triggers when a record is committed, and it exits with a result of `False`, then FileMaker won’t commit the record. In this way, your scripts can gain a little control over the under-the-hood behavior of the application itself.
On the layout, you can trigger scripts in these scenarios:
* **`OnRecordLoad`** fires when a new record is “loaded” when the user is on the layout. In other words, when the user flips to a new record with the book icon, performs a find, makes a new record, and so forth.
* **`OnRecordCommit`** triggers when a record is committed. As mentioned before, this action can be canceled by the triggered script.
* **`OnRecordRevert`** kicks in when a record is reverted. This one is cancelable too.
* **`OnLayoutLoad`** fires when you switch to the layout. Imagine leaving the Status toolbar unlocked, and performing special finds, sorts, and so on automatically as your users switch layouts.
* **`OnLayoutKeystroke`** has the power to act with every keystroke. This is sort of the super-power trigger, allowing you to build single-stroke navigation systems, filter keystrokes based on criteria, and probably a thousand other as-yet-unimagined things. As you probably guessed, your script can cancel the keystroke, as though it was never pressed.
* **`OnModeEnter`** runs a script when the user switches to one or more specified modes. You could switch to a print-formatted layout automatically whenever the user goes to Preview mode, or use a special layout for Find mode, for instance.
* **`OnModeExit`** is a slight variation on `OnModeEnter`: it fires right before you leave a mode. This way your script can see which mode the user is switching _from_ and can even cancel the switch if you want.
The triggers for layout objects are:
* **`OnObjectEnter`** lets you know when a field has been entered, a button or tab has been tabbed to, or a portal row has become active. It also fires when you click on the page in a web viewer, or tab to a field on the page.
* **`OnObjectKeystroke`** is just like `OnLayoutKeystroke`, except it only jumps to action when you press keys while the object has focus. In other words, when you’re clicked into a field, or a button or tab control has the thick black border you see when you tab to it. As before, you can cancel keystrokes.
* **`OnObjectModify`** is the swiss army knife of triggers. For fields, it triggers whenever you’re in the field and change its value in any way (by typing, deleting, pasting, cutting, and so forth). Incidentally, it does not fire if you drag text from one field to another since, by definition, you’re not in the field you drag to. Bummer really. Many times, if you think you want an `OnObjectKeystroke` trigger, you really want an `OnObjectModify` trigger instead. For instance, `OnObjectModify` doesn’t fire when you use the arrow keys to move around in a field, or when you tab to another field. `OnObjectKeystroke` does fire in these situations, making it more powerful, but also much more difficult to work with. Finally, `OnObjectModify` also fires for tab controls when you switch from one tab to another.
* **`OnObjectSave`** does its thing when you finish making changes to a field. You can type, delete, cut and paste, and otherwise mangle the field’s data to your heart’s content without firing scripts. Then, when you tab out of the field, commit the record, or otherwise cause FileMaker to get you out of the field, the `OnObjectSave` field kicks in. It only fires if the field was actually modified, and it can cancel, meaning the user is not able to exit the field until they satisfy the demands of your script.
* **`OnObjectExit`** works just like `OnObjectEnter`, except it fires when you leave the object instead of when you go to it. Once again, it is cancelable, which prevents the user from moving on to something else.
It is worth noting that the power to _cancel_ runs deep. If you write an `OnObjectSave` script that exits with a `False` result, FileMaker won’t let the user leave the field. Period. Even if she tries to switch to a different record, change layouts, close the window, or even quit FileMaker. In every case, the action will simply not happen at all. It is up to your script to provide reasonable feedback to the user (like a custom dialog box or a beep). And of course, if you make a mistake and your script always exits this way, you’ll essentially be stuck in the field forever, so you really need to be careful. (Luckily, triggered scripts work perfectly with the script debugger in FileMaker Pro Advanced, so you can just turn on the debugger, exit the field, then kill the trigger script to work around your troublesome code.)
I’d be a fool to try and predict the kinds of techniques we’ll see popping up [here][fm-mag] and [there][sfr] once people really begin to explore script triggers. I think this is one of those game-changer features: Ball’s in the air and it’s anyone’s guess where it will come down.
[fm-mag]: http://filemakermagazine.com/ “FileMaker Magazine”
[sfr]: http://sixfriedrice.com/ “Six Fried Rice”
> Note: A new View -> Show -> Script Triggers menu command was also added in Layout mode. Turn this on to see a little red star icon attached to any object on the layout that has script triggers. This is super useful, for instance, to help keep you from accidentally duplicating a trigger-happy field for some unrelated use.
##Sub-Summaries Like Never Before
This is a feature that’s easy to explain, requires almost no new learning, and will knock your socks off. Everything you know about sub-summary reporting now works in Browse mode. It’s almost magical to see elegant grouped lists instantly adapt as you edit records, and change the sort order, all the while remaining fully clickable. In this case, a video says it better than words:
>Note: You can download the sample database used in the video here: [People.fp7][ssdemo].
[ssdemo]: http://sixfriedrice.com/wp/wp-content/uploads/2009/01/peoplefp7.zip “A sample database showing live sub-summaries in action.”
##The Persistent Sort
If you paid close attention to the video above, you may have noticed something else new: Records stay sorted. If you sort your contact list by City, for instance, then update the address for someone who moved, the record you edit will instantly jump to the correct sorted position. In other words, the storied state of “semi-sorted” is almost a thing of the past. (“Almost” because it can still crop up when importing records into a sorted list, or when using the Replace Field Contents and Relookup Field Contents commands.)
In truth, once you get used to this behavior, you’ll probably wonder why it didn’t work this way all along. It just feels natural. Best of all, you don’t have to do anything as a developer to take advantage of this feature. It Just Works™.
##Find and Find Again
Here’s another feature that’s more for the users than the developers, but it’s still super cool. The Records menu now has a Saved Finds submenu, where FileMaker keeps track of the most recent find requests you’ve used, lets you perform them over again, and even lets you save a frequent find with a special name. You get the same menu if you click-and-hold on the Find button in the status toolbar:
If your users often perform the same finds over and over, they no longer need to beg you to write them a script. Instead, they can do the find once, then choose Save Current Find… to add it to this menu. Now, the same find (with as many requests and criteria as they want) is just a few clicks away.
The list of saved finds is stored with the user’s account, so if your users each log in with a separate account (even with External Authentication), they’ll have their own persistent set of saved finds. What could be simpler?
##Send Mail the Old Fashioned Way
There are two kinds of people in the world: Those who see the following picture and think, “It’s about time!” and those who…don’t. Which one are you?
Starting with FileMaker 10, your scripts (and users, if you so desire) can send email directly through a so called SMTP Server (in other words, an industry standard email handling system). When you send an email this way, it bypasses the mail program on the local computer completely. You don’t have to worry about configuring an email client on a robot computer, or supporting Lotus Notes version 9.2.8.8.3.1.3, or confusing your users with mysterious pop-ups. Instead, your FileMaker solutions can act just like real email programs, delivering any message you want to anybody you want with no interference.
You can even customize the email address the message comes from, so long as it is allowed by your mail server. Put another way, you can now send email quickly, cleanly, and reliably without special plug-ins. As an added bonus, when you use this option in your scripts, they can be run by FileMaker Server as a scheduled script.
Don’t be lulled into thinking you should always use the SMTP Server option in your scripts though. The older behavior is still available (and the default) by way of the E-mail Client option. And it is still the right choice if you want your users to customize the message before it sends, or if it is best for them to see it in their Sent Mail folder. Now, you get to decide which model works best in each situation.
And remember, this feature should be used only for good, never for [evil][spam].
[spam]: http://www.spam.com/
##All Hail the Tab Order
Have you ever had to add a new field to a layout that has lots of fields and a very particular tab order. If so, you have, no doubt, cursed the engineers at FileMaker Inc. a time or two, while you click…every…darn…field…over…again. Apparently one of those engineers ran in to the same problem when helping his girl friend keep track of her antique Pez dispensers. Because that guy, bless him, stayed late one saturday night and fixed the problem.
As of today, my friends, you can now insert a field into the tab order. For example, suppose you already have fields numbered 1, 2, 3, 4, and 5. You then add a sixth field to the layout, which really should go right between 2 and 3. No problem: Just choose Layout -> Set Tab Order, put a 3 in the arrow by the new field, and marvel as FileMaker renumbers the rest for you. 3 becomes 4. 4 becomes 5. And yes, ladies and gentleman, for a limited time only, 5 becomes 6.
We’d call this feature a great leap forward, but seriously, when you have nowhere to go but up, it’s more of an obligatory lurch forward. None the less, thank you engineer dude. You’ve given us our lives back.
Hold on to your socks. In FileMaker 10, _users_ can now add fields to table view without visiting the layout. This adds a level of dynamic data access that has never existed before, which is a great step. Now you can configure a table view layout for your users, and let them add or remove fields as they see fit:
Many of you will gasp in horror at this, though. Now it is painfully obvious that a field that is not restricted by a Privilege Set is wide open for view *and* edit by a logged in user. That means someone can go to a table view layout, click Modify and add the Password field to the list, or drop in the Cost field and modify it. (If you keep the status area hidden and locked, then this feature is locked away too, so nothing has changed for you.)
Of course this was always possible in a more round about way: If you have access to a database, you can use its tables in a *new* database of your creation, where your access to fields is limited only by your privilege set. But a lot of people ignored this problem either because they were unaware or considered it too obtuse [ed: er…abstruse, see comments below] to worry about. Now poor access privilege settings can lead to trouble much more easily.
The _correct_ solution to this problem is the same as it always has been: Depend on privilege sets to control who can see and edit what data. And “Run with full access” scripts to work around the restrictions as needed.
Alas, this is a difficult change to make. If you are willing to live with the sort of half-baked security you’ve had all along, the simpler solution is to turn off Table view access for all relevant layouts. This can easily be done in the Layout Setup dialog box. Once you do this, users will no longer be able to pry in to fields without the level of effort required in 9. (And remember, if you have the status area hidden and locked, the user won’t be able to get to the Modify button in the first place.)
>Note: To reiterate, blocking table view **is not secure**. But if this new feature causes you trouble, then **your system isn’t secure in 9 either**. So it is a quick method to get back to the slightly more obscure insecurity you had before. As always, we recommend you use proper security if security really matters.
##Indirection
FileMaker 10 has one new feature that will almost certainly prove to be a sleeper sensation. At first it seems so weird, so obscure, that many will wonder why in the world they would ever use it. But in time, as clever developers put it to use and share their experiences, I’m confident we’ll begin to understand its true power. I’m talking about a new script step called `Set Field by Name`, and its companion function, `GetFieldName`. The first works just like the `Set Field` script step you know and love, except that instead of choosing the field you want to set from a list, you use a calculation formula. For instance, if you want to set the First Name field, you could use a formula like this:
“Customers::First Name”
Or this:
Get ( ActiveFieldTableName ) & “First Name”
Or even this, if you like this sort of thing:
“Customers::” & LeftWords(“First things first”, 1) & ” ” & Filter(“Nxaxmxex”, “abcdefghijklmNopqrstuvwyz”)
To put it succinctly, the result of the calculation is the name of the field you want to set. So if you do this mind-bender:
Set Field by Name [ Globals::Name, “Something” ]
It is not the Name field itself that gets modified, but rather the field whose name is _in the Name field_.
Because storing field names in literal text values in your calculations is inherently fragile (if you rename a field, you script will break), FileMaker 10 also introduces the `GetFieldName` function. This function, at first blush, seems even weirder. Consider this formula:
“You have a field called ” & GetFieldName(Customers::First Name) & “.”
If you put this in a calculation field or a Show Custom Dialog script step, you’ll see this: “You have a field called Customers::First Name.” When a field is inside `GetFieldName` in a calculation, you get its _name_ instead of its _value_.
If this just confuses you, don’t worry. You’re not alone. The popular name for this feature seems to be “indirection” or “field indirection.” This is probably because it is tangentially related to a [computer science concept][indirection] of the same name. But I like the dictionary definition better:
[indirection]: http://en.wikipedia.org/wiki/Indirection
>_indirection_: indirectness or lack of straightforwardness
That about sums it up. Truthfully, although its use will be rare, it is an exceptionally powerful feature. You’ll see an article or two appearing here on SFR soon showing techniques that take advantage of indirection.
##Where to Print
When you use the Print script step, you can turn on the “Specify print options” checkbox to hard-code printer-related settings like the number of pages, the page range, collation, and so forth. In FileMaker 9 on Windows, in some cases, this checkbox would also cause FileMaker to automatically select the correct printer for you. In other words, if you wired the script to the printer called Sales Office Laser, then anybody who ran your script would get output on that printer too.
This printer selection never worked on Mac OS X, and it was a little flaky on Windows. As of FileMaker 10, it is an officially supported feature, and works seamlessly with any printer and on any platform. Now you can force the Fax printer driver in your script, or send bar code labels to the thermal printer, with no user interaction, and no messy plug-ins.
##File Recovery and Maintenance
The Recover process has long been a source of anxiety for even the most capable FileMaker developers. Nobody knows quite what it does, everybody swears off recovered files like plague-stricken corpses, and you have zero control over the process. All that changes in FileMaker 10. Witness:
We’ll have an entire article devoted to all these knobs and switches, but as you can see, you have a much greater (and possibly more confusing) degree of control over the recovery process. What’s more, FileMaker now produces a comprehensive log of the entire recover process, so you can see exactly what (if anything) it changed. On the down side, these logs are abstruse—you have to know a lot about FileMaker database internals to really make sense of them. Luckily, FMI has promised a whitepaper to help us mortals make the most of it. We’ll provide a link as soon as we find it.
On a related note, we should mention the [Milli Vanilli][milli] of FileMaker features: File Maintenance. This handy command made its debut in or around FileMaker 7, to the cheers of FileMaker developers everywhere. Its compress and optimize operations seemed to speed up our databases while at the same time making the files smaller. Many of us started performing file maintenance as a part of our regular upkeep.
But a couple years ago at the FileMaker Developer’s Conference, FileMaker personnel made an apparently official about face, suggesting that we should never use these commands. It turns out the ancient Save a Copy As command, with its “compacted copy” option, performs the same basic service. The difference is that file maintenance operates directly on the open database, which means if anything goes wrong, you can damage your file permanently. If you use Save a Copy As instead, you get a compressed and optimized copy. If a problem arises, the original file is still OK.
[milli]: http://en.wikipedia.org/wiki/Milli_Vanilli
Once this became clear, nobody wanted to use file maintenance anymore, and a few folks began to wonder why the feature even exists. Why offer an appealing, but unsafe version of an existing useful command? FileMaker apparently agrees. As of FileMaker 10, the File Maintenance command no longer exists.
##Miscellaneous Changes
No new version would be complete without a laundry list of relatively minor changes. Here it is.
###ESS Enhancements
FileMaker 9’s flagship feature was External SQL Sources, or ESS, so it is unsurprising that it ESS got a little love in 10:
* Value lists based on fields from ESS tables are now supported.
* ESS now supports Single Signon authentication with Microsoft SQL Server. If you don’t know what that means, you also don’t need it.
* DATETIME columns are now handled more intelligently with Microsoft SQL Server. You get to decide if you want just the Date portion of the value, just the Time portion, or both.
* You can now use the latest versions of MySQL and Oracle with ESS.
###A Few Good Functions
FileMaker 10 adds five more calculation functions we haven’t yet mentioned, and makes a subtle change to a sixth:
* The **`Char`** function creates a text character from its numerical equivalent. Now you can insert a Line Feed character in your calculation easily: `Char(10)`
* The **`Code`** function works opposite to `Char`. It gives you back the numerical equivalent of the text value you pass in. This is critical information when building scripts for Keystroke triggers. It allows you to handle complex keys like `escape`, `enter`, function keys, and so forth.
* The **`Get(TriggerKeystroke)`** and **`Get(TriggerModifierKeys)`** functions tell you which keys someone pressed to fire you `OnLayoutKeystroke` or `OnObjectKeystroke` script triggers.
* The **`Get(DocumentPathListings)`** function returns a list of paths to every file in the user’s Documents or My Documents folder. Again, I’m not sure what inspired this function. It seems odd that it is limited to just the Documents folder, but I’m sure there’s a reason in there somewhere.
* The **`Get(TemporaryPath)`** function has changed just a touch. It now returns a path to a special folder *inside* the user’s temporary items folder. Anything you store here will automatically be deleted by FileMaker when it quits. Before, files would stick around until the operating system decided to clean them up, potentially wasting space. In general, this should not effect your scripts at all, unless they make the (faulty) assumption that files created in the temporary folder will be there across restarts of FileMaker.
###Import and Export Formats
FileMaker can now import data directly from [Bento][bento], the Mac OS X only consumer database program FileMaker Inc. released last year. Time will tell if it proves useful, but this means you can now import data from the Mac OS X address book and calendar into FileMaker by way of Bento. Let us know if you come up with any cool uses for this.
[bento]: http://www.filemaker.com/products/bento/features.html “FileMaker’s Bento application.”
In addition, a few prehistoric formats are no longer supported for import or export: SYLK, DBF, DIF, WKS, and BASIC. Honestly, we might miss DBF a little, but the rest we haven’t used in years, if ever.
Finally, FileMaker can now import and export the new .xslx format used by Microsoft Excel 2007 for Windows and 2008 for Mac OS X.
###Edit Scripts Tweaks
The Manage Scripts window has seen some minor changes too. Script groups, which were first introduced in FileMaker 9, are now called _folders_ in keeping with their function and icon. Also, you can now create an empty script (just like before), or a so called Default Script, which, in homage to FileMaker 5-ish, is a script with a few pointless steps already inserted. I guess the idea here is to show people what a really small script will look like. Thankfully, Empty Script is still the default, so that’s what you’ll get if you just click New.
###Etcetera
Some things really only warrant a bullet point:
* FileMaker now supports IPv6 for database sharing. We don’t have enough expertise here to comment, except to say, “sounds good to us.”
* The QuickStart panel, another FileMaker 9 newbie, has been redesigned a touch. It now includes recent database, a favorites list, and more. In other words, I haven’t turned it off yet, which is a first for me.
* A new Launch PHP Site Assistant command in the Tools menu gives you quick access to this web site builder if you have it installed.
* The Database Design Report has (duh) been enhanced to cover script triggers and the other new FileMaker 10 features.
* The Starter Solution (template) databases included with FileMaker are now a little less embarrassing. For instance, they actually use real tab controls now. And normalized tables. And other features introduced in the last five years.
* My notes say there is no longer a hard copy User Guide in the box. I suppose someone out there will care, and with you, I condole.
##Another Year(ish), Another Release
FileMaker has been progressing so steadily since the 7 release, that it would be easy to get a little jaded. But when you look at it objectively, you can’t help but be impressed. I find it heartening that FMI put time into big new power features like script triggers and a less bullet-point-worthy but equally important user interface overhaul. This release certainly looks different, but it also has enough new power to keep people like us busy finding new solutions for a good while.
Also, I don’t talk about this much, but because I write [books on FileMaker][amazon], I typically get to play with the software a little bit before release. I’ve been lucky enough to get pre-release access to most versions of FileMaker since 5.5, so I have a lot of experience toying with new releases at night while I use last year’s model all day. It took me a few days to get used to the new interface in 10 (I kept trying to show the already-visible status area, for instance). But once I was in the groove, I suddenly found FileMaker 9 to be aggravating in ways I’d never noticed before. I think this is the first time that’s happened.
The new release completely supplanted my subconscious expectations almost over night. The Layout bar, the Preview button, the Formatting bar, the Status toolbar—all these little changes seem, to me, to fit the way my body wants to work better than FileMaker ever has before. I now feel like 9 is clunkier, like my workflow in 9 just isn’t as smooth as it is in 10. And for a software product I’ve been using almost daily for 15 years, that’s really saying something. I wasn’t convinced at first glance, but now I’m impressed.
[amazon]: http://www.amazon.com/exec/obidos/search-handle-url/ref=ntt_athr_dp_sr_1?%5Fencoding=UTF8&search-type=ss&index=books&field-author=Geoff%20Coffey
Only one question remains: Where do they go from here? You almost never see a Version 11 in major software. CompuGlobal Hyper FileMega Pro 1.0, anyone? Cheers, FMI, and cheers, FileMaker community. Let us know what you think in the comments.
Theres a number of features which stand out, although ive been playing around with the pre-release you have obviously done so in more depth so if I may can I ask a few questions, since im yet to install the final release.
1. Can the new toolbar be re-anchored to the left or is it fixed (when shown)
2. With the changes to print script steps, is it now possible to store print options such as 2 pages, landscape, A4 however not set a printer. To explain why, I script various layouts to print using a variety of options, however my solution is bound as a runtime, therefore the printer will be different on each machine, so scripting a saved printer is a definatly no, I use myFmbutler at the moment for this.
Great article by the way
Steve:
1: No, it is top-or-nothing. If you think about it, it would be tough to put some of the wider elements into a sidebar (like the new wider layout pop-up menu and the record info indicator). I’m not saying they *couldn’t* find a way to squeeze some or all of it to the left, but I think it would be tough. (Don’t forget button labels that have to be localized to German, with is long long words…).
2: That is a good question. I honestly haven’t spent much time playing with the new print setting stuff. (Susan wrote that portion of the book). I’ll investigate and post back. I can completely see why you would want both possibilities.
Geoff
Thanks, dude. Will you do a post on FM Server/Adv 10 also? Like today? 😉
@Chris – It’s on it’s way 🙂
Minor quibble on the grammar:
it triggers whenever your in the field and change its value
Should be
it triggers whenever you’re in the field and change its value
Or
it triggers whenever you are in the field and change its value
Do you know if the GetFieldName() can be used without arguments to return the name of the field that holds it ?
Ex. : if a field name is LastNameXML and its calculation is : left(GetFieldName(),len(GetFieldName()-3)),
then the field LastNameXML would display the LastName field name.
It may seem useless but, if the formula was modified to automatically add the xml tags and combined with the GetField function, it would really be a time saver as one would only have to duplicate and rename the calculated field to get properly tagged elements.
Bruce:
Thanks. Fixed. I suspect I didn’t tell you much you didn’t already know, so thanks for taking the time to read through it. 😉
Geoff
Michel:
Interesting question (and a little mind bending). I think I see where you’re going. I tried this:
In a calculation field, and it returned the name of the field, so I believe that will do what you want.
Geoff
Hi, In one of my solutions I needed to show which fields have been changed with conditional formatting. I used an audit log to keep track of changes. (I cleared it after a save so it only track changes after a save). Lets say I wanted to change a field’s text to read if there was a change. How would I do this in 9. I would have to have an if statement for this. If patterncount (fieldname) >0 then text is red. I would need to have a separate statement for each field. If I have 200 fields, it is too much. Now I have pattercount(getfieldname)>0 then turn red. It works for all my fields now. It allows a field to know it self.
Oreste
Thank you Geoff,
It is exactly what I was looking for !
I hadn’t upgraded from 8.5 to 9 (was waiting for 10) therefore didn’t think to check for the Self function introduced in fmp9.
Last year, I did a complex XML conversion script and it would have saved me some days of work.
The GetFieldName is something I asked on the FileMaker Feature Suggestion site a couple of months ago and never thought they would add. Thanks guys !
I am looking forward to your comments on FileMaker pro Advanced 10. The FileMaker site doesn’t say much on “Advanced only” new features (although I think that the regular version new ones are great combined to what is already available in Advanced, I do tend to think that if it is more expensive, it should do more).
Does the runtime engine now support printing to PDF? If so, this would be a big advance. TIA
Oreste: Very cool concept. I think this is really going to be an enabling feature for all kinds of powerful techniques.
Michel: Understood. Sounds like a cool project. As for Advanced, I don’t think much has changed. It still differentiates from Pro by way of the Debugger/Data Viewer. In fact if I’m not mistaken, in 10, some features like Tooltips, which were previously Advanced only, are now in both. And Script Triggers, which is clearly a high-end developer feature is in Pro, which seems a little odd. But it looks like FMI is trying to keep the core feature sets the same, and focus on the tools for differentiation. I suspect this is because they want to avoid confusing people who do minor development in Pro on files that were build in Advanced.
Michael: No, I don’t think so. I don’t think you’ll ever see that happen unless something substantial changes. My understanding is that the license fee FMI pays to Adobe for the PDF engine is priced based on the actual application. Legally, they would have to pay the full fee once for every runtime someone builds, rather than just once for Pro and once for Advanced. So, which is is technically simple, it is legally impossible.
Geoff
Thanks, Geoff, this is pretty extensive.
And thanks for all your hard work in this community!
Agi
Geof: A comment about FMP Advanced pricing.
If the tools are the only difference, the Advanced version users have already paid for these in the previous version.
Why charge 120$ more to only get what Regular version users get ?
They should be able to upgrade from advanced version to advanced version at the price that regular users pay.
If a regular version user wanted to upgrade toward advanced, then the difference in price would be justified (but in the FileMaker shop its the same).
I’ve always had a hard time with FileMaker’s marketing politics.
Geoff! I love it when you prevent me from doing my own write up on the magazine site! What a time-saver! Really, thanks so much for doing this. It’s great to see such great content.
Using your article for reference, I’ve posted the quick list of new features here. Anyone is welcome to edit and enhance.
Where do they go from here? Well, dragging the graphics tools into the 21st century would be nice… Kinda’ tired of the MacPaint graphics…
But, I must admit, I squee!’d when I read ’bout the script triggers. And the Indirection features– I was trying to figure out a way to do that last month.
Thanks for the great overview–
Dane
Michel: I understand what you’re saying. I can see the reasoning there. We have a site license, and so do most of our customers. It is sort of all-in-one in that case, so I never gave it much thought.
Geoff
Matt:
Thank you for the link. You rock. Did you spot my tiny link to your site? Fun stuff. New FileMaker releases make me giddy.
Geoff
I would like to see an actual database language – similar to 4D – which can run simultaneously in place of the script language.
I would love to see this language in a compiled version as well.
Actually, I would like to see a fusion of FileMaker and 4D. That would make it the best of all worlds.
I followed on with a little more testing of the Stored Printers in the setup script and really wish FM gave us a little more to work with here.
Its all good and well if you know the printers which are going to be used, but for us ‘shrink wrapped’ developers it is actually making things worse.
I setup a few random scripts to goto one of my printers using various options, most important being the record option under Print Script step being ‘records being browsed’ for this example anyway.
Since this is the only way to store this option, it is now as documented storing the printer also.
Try as you might, without editting the script step, to use a diffferent printer. The only way I found was to actually rename the printer in windows control panel.
I really think FM needed to include a few more print options such as :
Print SetOrientation (landscape etc)
Print SetRecords (all, browsed etc)
Print SetPrinterName (whatever you want or default)
I dont understand how they expect us to be able to edit and save a printer name for what could be thousands of clients & systems along with god knows how many printers
Either that, or a script step to force FM to re-evaluate the windows default printer.
//Rant over
Other than that, the script triggers especially in real time open up a whole new level of exploration, I briefly looked at a way to physically limit characters being entered in a field with the new triggers its possible since they evaluate as you type. Currently in FM9 you can validate, but it still allows unlimited (almost) input before validation however with a few tweaks, In FM10 I will finally be able to lets say limit card number to 14 digits and make it jump to the next field on completion. Trivial i know, but it also allows for less user error / annoying popup dialogue boxes with the [revert field] button.
I like the idea of the new Status Toolbar however it would have been nice if it were possible to define a script to operate behind the buttons and/or add our own custom icon/buttons combinations. In some cases it’s necessary to control the way these standard record handling functions execute, i.e. new, duplicate and delete.
I guess it might be possible to combine the new script triggering features for new/duplicate record creation but I’m not sure about deletion.
Any thoughts on this issue?
Sean, I thought the same myself
Maybe im missing something, but when you goto customise the toolbar there are options for New, Rename, Delete etc
These are greyed out (unless its me) so perhaps its something they are still working on
Shaun:
You have just a touch of control here. First, if you redefine one of the core menu commands to run a script, I believe the toolbar button will run the script too. For instance, if you make the existing New Record menu command run your own custom script, then the New Record toolbar button will run your script.
Also, if you rename a core menu command, the associated button in the toolbar will reflect the new name.
I plan to test this further and we’ll probably write it up at some point, but I think those both work.
Geoff
Whoops, Sorry Shaun I read your name and misspelt it instantly, to used to typing Sean I guess.
Thanks for taking the time to write this enhanced list of 10’s new feature set. It is much appreciated by myself, and others.
As good as it seems I still miss Layers and Styles.
Thank you God though for creating what should have been done in v1: Edit the Tab order!!
Geoff:
Did I read somewhere that the new Script Triggers will allow for a ‘Timing’ element. Where the script is triggered and then it repeats via a preset time (minutes,seconds,hours).
Thanks for your article and keep up the good work.
Gary
With respect to the new CODE function, I have been using it in conjunction with the onKeystroke triggers. The Get(TriggerKeystroke) step will need to be ‘decoded’ with the code function to determine some of the system keys (ie ESC).
Thanks for the great overview. Set Field by Name gets my vote of best new feature.
Gary Wallis:
Within script editor there is a new step called
Install OnTimer Script which lets you choose a script to trigger and set an interval, is this what you meant ?
Quote from FM help file
“This step repeats until the window in which it is running closes or its options change. You can also halt the step by specifying another Install OnTimer Script script step for the window with no script specified.
The default interval is zero; you must specify a script name and an interval”
“Only one question remains: Where do they go from here? ”
Well one glaring omission is the ability to add constant values to relationships and/or portals. I’m getting tired of creating stored calculated fields just so I can build a relationship based on WHERE a.aID = b.aID and b.color = ‘blue’.
It would also be nice if the WPE could see databases on a different server.
Still this is huge. The script triggers, server side automated imports and exports, and value lists from fields in ESS will have me cajoling our IT department to get everyone upgraded as soon as possible.
Gary:
Yes, I didn’t cover it in my script trigger discussion here (whoops…). It is a little different. In a nutshell:
run the
Install OnTimer Scriptscript step, specifying a script and a number of seconds. Now your script will run every [n] seconds so long as the window remains open.You get one timer per window, so to change the script or timing, just call
Install OntTimer Scriptagain. To turn it off completely, either close the window or callInstall OnTimer Scriptwith no script specified and/or zero seconds.Geoff
Edit: Ahhh… Steve beat me to it. Thanks!
Sean:
Of course you are absolutely right. I have no idea what I was thinking when I wrote what I did. Readers of my book will see a simple keystroke trigger example in Chapter 15 that makes use of the
Codefunction for exactly the reasons you describe. This function is critical for keystroke triggering.Thanks for the reminder. I have updated the article.
Geoff
Norm:
Re: constants in relationship predicates, I could not possibly agree more. I’ve been wishing and asking for this for ages (along with a rethink on the entire Edit Relationship dialog box which, to me, seems very weird).
As for WPE…alas, I never use it. Never once deployed anything in IWP outside of just testing/playing around. It is interesting to see so much interest in it these days.
Geoff
I don’t use or like IWP either, but from what I can tell automated server side scripting uses the WPE. In order to speed up searching in some of our more complex systems I’ve build a number of ‘Index’ fields that are maintained by nightly scripts which load related data into local fields. Users can then preform a ‘fast’ search on the nightly index or a ‘slow’ search on the actual field containing ‘live’ data. We have two Filkemaker servers, and it was a rude awakening when these scripts failed on data located on the ‘other’ server. I worked around it by writing php scripts to do the same thing and managing them with cron, still it would be nice to use server side scripting for this kind of thing.
The one bloody obvious ‘where-do-we-go-from-here’ feature I didn’t see you mention is some form of layout management. I really want to see a *true* ‘Manage Layouts’ system that’s as much an advance over the current system as the new script management tools were for scripts in Filemaker 9.
Norm:
I see, and I agree 100%. When server scripts were first introduced, I was hopeful we could replace FM-Client based “robot” machines with a single second server install that scheduled and ran scripts hosted on the main server, but this doesn’t work.
Alas, I’m often not willing to run a lot of heavy scripting on the server itself, so it was back to robots for us…
Geoff
Travis:
I agree completely. I wish for this very much.
Geoff
RE: targeting printers for “shrink wrap” solutions
Couldn’t you have some fields (globals in prefs maybe) or a table even of printer paths that your end user completes and your scripts use? I know I am reaching here…
re: Travis / Layout Management
I couldnt agree more, with well over 500 layouts in my system as it stands, I really wish they put in some ‘grouping’ options like the script manager
re: Cannon / Targetting printers
Unless theres something I have missed with FM all of this time, what you mentioned is exactly what I think FM needs, a way to allow us to pass a printer name (without a plugin) from a global or variable, or at least force a reset to windows default.
Im currently using a plugin, which is very good and works a treat, however when first going with this I had immense problems, after managing to reproduce a virtual image of XP with the problem and upload it to them, they sorted it out, However every so ofter another strange occurance crops up with the odd client’s machine which I am unable to fix since its a plugin fault, nor can I reproduce it without sending them a disk image of the clients pc (impossible in some cases)
Really, my wishes where to get away from plugins for what should be somethign as simple printing.
This has and will always (unless they fix it once and for all) be my biggest concern with FM, everything else is all bells and whistles.
Ultimately, I wish FM would keep the user friendlyness, but also give us an option to dig a little deeper if we require (via FM Advanced)
I may be wrong, but the 3 steps I posted above would solve an awful lot of issues for most people in my opinion, anyhow enough of the negativity from me, theres always a way to work around things.
Regarding relationships, here is a little teaser for a technique I’ve been evaluating. One field match only, child side field is the recordID. Collecting and managing the left side keys, you can do all the filtering in the world.
I was sent this link by a coworker who is a big FM fan, and I find this all a little odd…
So, FileMaker Pro was released in 1990 and FileMaker Pro 7 was released in
2004. That’s 7 releases in 14 years (one release every two years).
However, since FM 7, there’s been four major releases (8, 8.5, 9, and now
10), which is 4 releases in 5 years (2004,2005, 2006, 2007, 2008).
That’s one major release every 15 months. That’s a very aggressive release
schedule, but if they know the FileMaker community is willing to
continually shell out the money for that, I guess it makes business sense for them.
But.. I know you guys are all probably diehard fans, but I’m just curious what you all think about FileMaker’s rapid release strategy? FileMaker was always pitched to me as an cheap alternative to traditional DBMS platforms, however, considering the cost of updating servers and clients every 15 months, how is this cost effective, especially compared to open source solutions like MySQL or postgreSQL?
And I mean that with all due respect…
Best,
Chris.
Chirs:
Die hard fan? Moi? 🙂
I guess you can look at it many ways. A rapid release schedule almost certainly means more revenue for FMI (which I honestly think is a good thing, but that’s the fan boy in me talking). But it also means less disruptive, more consistent updates, and new features faster.
In fact, a lot of the gripes I’m hearing with respect to 10 have to do with the 2 years it took to release. People were hoping for something sooner.
Also, I don’t have the history in front of me, but I believe there was a relative dry spell for a while before 7, because 7 was a huge undertaking. So perhaps the quick releases of 8 and 9 were in some ways influenced by a need to recover from the big development costs and revenue shortfall it took to get 7 done. (Of course FileMaker is a private company so we can’t know any of this with any clarity.)
In general, though, I think your point is sound. The software business has a terrible flaw: there is a powerful incentive to always add more. In a developer tool package like FileMaker, you might be able to follow this path for a long time, but in general, I think software packages tend to get more and more complex or overburdened in the unceasing quest for the next release, and the end result is self destruction. I point to the primary Adobe applications as examples. They have somehow managed to get progressively worse for most users over the past several years. But Adobe can’t say “We’re going to stop adding features and focus on stability and simplicity” because it takes revenue to offset the investment in the product, and consumers have thus far been unwilling to pay without teh shiny.
Apple is taking an interesting approach with the next release of Mac OS X. They have publicly said the release will not focus on features. Rather it will focus on stability, security, and consistency. I suspect lots of people will complain, but I give them kudos for caring enough about product quality to do it anyway. We’ll see how it pans out. I’ll pay for stable any day.
So what is the solution to the software problems? Maybe we just embrace the flow. Software comes, it dominates, it self destructs, and niche products eat its lunch, then the whole cycle repeats. The unfortunate part about that is that you never reach a point of true stability.
Another possibility is SAS. Maybe, just maybe, the “web 2.0” or “cloud” stuff will save the industry from itself by legitimizing a model of recurring revenue for software. We’ll see.
Anyway, you got me babbling. Sorry 🙂
FileMaker => Awesome. Just accept it. I’m going to go back to shining my Shrine to Dominique now.
Geoff
@Norm
I’m guessing most, if not all, developers, want “real” GUI widgets, not the “retro-80’s” ones as Geoff describes them. It’s a frustrating limitation.
Sean
When will Filemaker give us some control of page layout for printing – I had hoped they would look at this in FMP10?
If you are setting up a form letter that needs to extend over two pages, you have absoutely no way of controlling where text breaks. You can only have one header or footer on a print. You can’t set up a print job that assembles records from multiple tables or layouts. Image management for printing is non-existent. You can’t chain print areas. You can’t apply style tags to text fields when printing. You can’t use page templates to set up prints. You can’t change the layout to print multiple pages per sheet…
I’d be prepared to pay another upgrade fee for a version that gave us some improved print control capability – please!
Brian
Thanks for the reply. You’re definately a “glass is half-full kind” of guy.
I’m just concerned FMI is on an unsustainable path.
First, their core customers (like where I work) are small and often non-profits or educational institutions. To put it bluntly, we’re broke and will be for some time. So, FMI trying to increase it’s profits by squeezing their core users probably isn’t going to get as much in return as it once did…figuring out a way to increase market share, I think, would be a better avenue.
The problem is that even though Apple’s market share has increased, I don’t think FM has (I suspect it’s actually declined). The main reason is that all FM’s major competitiors offer their core software for free. Even Oracle and Microsoft have free versions of their servers and clients. FileMaker only will offer a demo for free.
To make matters worse, Apple and FMI seem to have a rather odd relationship. Last year’s FM 9 / Leopard fiasco showed the developers might not be on the same page. In addition, Apple doesn’t seem too keen on pushing FileMaker as much as it once did. Windows 2008 Server ships with SQL Sever, OS X Server ships with …. MySQL. A quick search on the Apple Developer Connection site, there are 23 articles that are returned for “FileMaker” and 270 returned for MySQL. Not sure what that means, other than Apple doesn’t seem as interested in hyping FileMaker.
All I’m saying is that 10 is an important number and I would have rather seen FileMaker’s 10 release show where it’s core is heading, rather than make a few UI changes. That PHP API was a good idea, but they need to crank the development process a bit. Like maybe make a robust CMS distribution that works with a FM backend?
Just maybe something that people can use that doesn’t cost them something upfront. I mean, that’s worked for Sun and Google, right?
I dunno…just a few thoughts. Thanks again…
Best,
Chris.
Wow, what an article is this!! Great!
With the coming of version 10, I just went into my old vs 9 applications to be prepared of number 10.
One very painfull thing, is the list-view in 10 with te possability of users to add fields, no matter from where over the complete application. Every field is possible to add in the view, and more painfull, to change the content of the fields.
Also keyfields…
Your advise was using the Priviliges sets is the right answer to solve this problem. A good advise, knowing all about safety.
But…
I have a portal with a child-table. It makes sense to me to set the key-fields of the parent and child table as Read Only.
But… adding new records in a portal doesn’t work anymore, because Filemaker is also protecting new records at the key-fields.
Both FM9 and FM10 comes back with the comment “This action cannot be performed because this field is not modifiable.”
What to do??
( I ask it here because you made a very good story, tells al lot of your knowledge of FM!)
Geoff & Norm:
I think IWP is the best thing since sliced bread. It enables me to incorporate some databases (eg. staff/student photos) extremely easily into our school’s intranet. I don’t need the sophistication of php, just a simple, quick & efficient way of creating a web interface.
As for v10, the new features are certainly welcome and in part even exciting, but I was really hoping for a modernisation of the ‘MacPaint graphics’ (Dane). FM has fallen a long way behind other applications, in giving the designer the ability to easily create modern looking interfaces. My experience as a developer tells me that for the average client, it is vital to design an appealing and engaging interface – this what makes them want to use the database in the first place. It’s similar to buying a new car – what’s really important is its ability to transport us efficiently, comfortably and safely, but an appealing design trumps all other factors.
We run two systems, my FM system and a commercial SQL system. The latter is more powerful but has a clunky and boring interface. People LIKE using the FM system and use it in preference because its interface is better designed and visually more appealing.
Geoff:
In Layout Script Triggering is there a way to trigger when leaving a Layout?
It is my impression that once you ‘set’ a Script Trigger Timing sequence it continues until you send another Trigger that does nothing. It would be nice to be able to start a timer when entering a Layout and then stop it when you leave the same layout. Or am I just missing something?
Gary
Wim:
I think the right answer for key fields is to allow edit via privilege sets, but set the field itself to “prohibit modification of field value.” I believe you will still be able to auto-create related records, but users won’t be able to modify the value later. I might be wrong though.
To be perfectly honest, it is really hard to truly secure a database using privilege sets. It requires a very aggressive set of restrictions, and careful use of scripted actions with “Run with full access privileges.” That’s why a lot of people just punt, ignore field-level security, and lock things down as best they can. In 10, an additional lock-down step would be to turn off table view access for each layout.
Geoff
Gary:
None of the layout triggers fires when *leaving* a layout, unfortunately. I highly recommend you use this form to let FMI know you would find this trigger useful. The UI of the script triggers feature in 10 strongly suggests that adding additional trigger types in the future is part of the plan.
As for today, you might get away with a little workaround. First, install your OnTimer script like this:
Then wrap your trigger script in some logic like this:
Now when the timer is installed, the current layout name is noted. Then whenever the timer script runs, it first checks to be sure you’re still on the right layout. If not, it uninstalls itself. Otherwise it runs like normal.
This isn’t exactly like what you describe, but in practice it might be close enough to meet your needs.
Geoff