FileMaker 11 added just one new object trigger, and it is a strange little dude: `OnObjectValidate`. This trigger fires after you edit a field, before it is validated. If you thought FileMaker already had enough after-you-change-a-field triggers, you were mistaken. In this article, I explain how the various field triggers fit together and why `OnObjectValidate` exits. You then get a simple example of how it can be used. And as a special bonus, I show you how to extend the technique so it can easily be reused over and over again.
We start our return to semi-regular writing with a small-but-awesome custom function: `Pop`. If you grew up in the American mid-west like me you might think I’m talking about [soda|soda pop|coke|soft drinks]. But I’m actually talking about [stacks][pop]. In the computer science world, `pop` means to take something off the top of a list, and it is exceptionally handy to make it easy in FileMaker scripting.
Let me start by saying: “Ouch.” It has been far, far, far too long since our last article. Someone much wiser than me once said something like this: “My only comfort is that I tried. My only regret is that I failed.” I’ll leave it at that.
In short order, I’ll be posting our first new article in over 18 months. But first I thought I’d share a little news. For those who are here for great FileMaker info, feel free to skip ahead. (And let’s be honest, that’s the only reason *any* of you are here.)
In the last post about the Six Fried Rice methodology I went over the concept of data separation and why we use it. That is essentially the starting point for how we structure the files of our system. One file contains all of the UI components and scripts for the system while a second file contains all of the actual data. Just doing that one basic separation provides several benefits that generally make life easier, but how we structure the data within the Base File itself is equally if not more important than the data separation.
A funny thing happened while I was stumped over the question of how to allow one of our clients to select and deselect multiple items in a list. Multiple people would be using the list at the same time. I was struck by the fact that I’ve been making something more complicated than it needs to be for as long as I’ve been working with Filemaker. After toying with various methods which included adding fields to the records in the list, join tables, global fields and horribly convoluted scripting it occurred to me that you can actually write a relatively simple custom function to handle it all. It will add or subtract a value from a list that is stored in a global variable and then simply do some conditional formatting to highlight the selected items in the list. No additional fields or scripting are needed, the global variable is session specific and once you are done you’ve got your list of data ready to go as is.
In an earlier article we explored an [isolation technique][isolate] that was specifically designed to work on ID’s and that’s it. There is a lot more that can be done with the new `Set Field By Name` step and in this article we’ll take a look at a slightly more complex but much more versatile search method. This technique will rely on the use of our dictionary functions, so taking a look at this [article][tab-article] is a definite prerequisite.
FileMaker 10’s new Script Triggers feature just keeps delivering. You might, at first, think triggers are limited to layouts and fields, but it turns out your triggers can fire with all kinds of objects. In this article we’ll show you how to run scripts when users switch tabs on your tab controls. In the end, we’ll also revisit a common FileMaker problem: tabs switch when you switch layouts. We’ll show you how to solve this problem quickly and easily using script triggers.
[FileMaker 10][fm10]’s most visible new feature is the completely redesigned Status toolbar (formerly called the Status *area*). Perhaps because of its prominent position, or because it is such a striking departure from a 20-year FileMaker mainstay, this change has been met with its fair share of controversy. In this article we’ll show you why you don’t need to worry, and how you can make the new Status toolbar *work for you*.
[fm10]: http://sixfriedrice.com/wp/introducing-filemaker-10/ “Our complete coverage of FileMaker Pro 10”
For years, FileMaker developers have been devising various *filter* techniques. The idea is that you type all or part of a name, part number, description, etc… and a list of results filters down to show relevant matches. As handy as these techniques are, they always stop just short of perfect because, before FileMaker 10, you had to *exit the field* before the filter would take effect. Using FileMaker 10’s powerful Script Triggers, you can make the impact of your filtering more immediate.
Script triggers have in many ways completely changed the game when it comes to Filemaker development. The fact that I can launch script triggers on mode changes opens up a whole slew of possibilities, one of which is being able to have a huge amount of control over where my users end up and what information they see while they are navigating my system. If I want to make sure that my users always have fields X, Y and Z regardless of how they get to find mode, I now have a way to make that happen.