Looping through and filtering lists of values turns out to be a common task in FileMaker. Having a few different techniques at your disposal is quite useful. In this post, we are going to look at a set of related techniques for processing lists. First we look at how to loop through each item and perform some function or task on each item. Then we will move on to a custom function for filtering lists by any valid FileMaker expression. Finally we will use another Custom Function to easily parse Layout Object Names from a layout and use them in a dynamic slide navigation scheme.
FileMaker’s GetField() function has always been struck me as a curious beast. Every since it’s release back in Filemaker 5.5 or there abouts I had assumed that it returned the contents of the field specified by the parameter. But there were a couple of cases where it didn’t work that way and I’d get fooled every once in while. I didn’t quite understand what was going on. I think I finally stumbled on an easy way to keep it straight. Read more
Unit Testing is the practice of testing individual chunks of code to make sure they are working as designed. Ideally it is done with a single click of a button, so that you can do it all the time. Traditional FileMaker coding doesn’t lend itself to this practice very well. It’s just too tightly coupled. But if you take some time to organize your code in a modular way you can start to incorporate something like Unit Tests into your development practice.
First you need to separate out the logic you want to test into well factored API like scripts. These can take parameters and they usually return a result. The main point is that you give these scripts the power to do what the need to do to your database, and you make sure that they report back if they fail or not.
Once you have your API scripts laid out you can the write yourself a bunch of test scripts that exercise those API script and make sure they are doing their job. I put my Unit Tests in a separate file so I don’t clutter up my deliverable files. Then as I go along writing code, I periodically go back and run all the scripts. When I do something that cause my tests to fail, I can see it right away. I know what test broke and hopefully I get some kind of error that might help tell me how it broke. From there, its relatively easy to go about fixing the code.
Here is a movie that shows what that ends up looking like.