ISO FileMaker Magazine

About 10 months ago, I released a video and file about Error trapping and logging. Since that time, I've improved my system and made it even easier to log the errors. As I mentioned in the previous article, it's really nice to see where errors are happening. You get a much clearer picture of any issues when they happen. When it comes to users, knowing as many details about the error the better - it sure does beat the conveniently vague "It doesn't work".

So you start using Set Error Capture [on] and you think you're good to go with Get ( LastError ). This is, of course, until you start performing multiple steps within one script which could cause errors and you want to log those errors to a log in order to review them.

Being notified about when an error happens and what type is also nice. Wait, "type of error"? Isn't FileMaker the only potential for an error? Nope, not quite.

You can experience any number of errors in your FileMaker solution. FileMaker errors, plug-in errors, custom function generated errors and your own application errors.

This means you need a robust system for handling and managing these errors. Fortunately, I've given you a great head start with this video and technique file!

One of the new features released in FileMaker 11 were Snapshot links. While perfectly fine for your average FileMaker solution, they aren't quite as useful when you've got a really custom setup running.

I'm talking about the kind of setup where your interface is driven based on global fields used to store keys in order to view related data. So, the assumption Snapshot links makes is based on your use of FileMaker the way FileMaker is designed - not necessarily the way you've designed your solution. They don't quite work for your custom layout based on one single record from a table full of globals used to view related data.

When you're using global fields to drive what is shown in a portal, or for showing related data then you've got to get creative to use this useful new feature. Fortunately, as is the case with many situations, you just have to "code it up" and make the solution work for you as well as it works for FileMaker's default behavior.

Thanks to Tim Anderson and a technique he sent in, I've added a few changes and made his Snapshot Launcher a solution you can use on an interface which uses global fields to drive the user interface output.

Whether you email, attach to a calendar, or simply save for later reference, you can use this Snapshot Launcher technique to bring back any set of data you can possibly imagine. It really is a powerful technique for today's cloud-based always-connected world!

Almost every, and I mean EVERY, developer has their own take on FileMaker development. I guess it's one of those aspects of FileMaker which is so appealing. Every developer can feel like they're controlling their own destiny and exercising their own creative power - even when they come up with their own standards.

Yet, in many, and I mean MANY (read, almost ALL) other programming languages (if you permit me to compare FileMaker to a programming language), there are conventions (or standards - of which I'm semantically using both words interchangeably). Not to say that FileMaker doesn't have these. In fact, over my many years of working with FileMaker, I've heard of hundreds of attempts to establish a standard for coding in FileMaker. Even FileMaker, Inc. released a white paper in 2005 after FileMaker 7 had been out for a while, where they documented a variety of suggestions. Even still, these suggestions came from many developers, of which each had their own styles of creating a solution - so the white paper read like suggestions instead of conventions or standards.

After attending Pause on Error in Portland, and hearing the number of people "claiming" they wanted such standards, I decided to start to do this for myself - knowing that decision by community is a slower process. While working on my upcoming product release called the Theme Studio, I spent a good deal of time focusing on making the code within the solution as readable as possible. The goal was the ability for any developer to be able to open the solution (even though it's a closed solution) and understand. Hence, I'm calling this the "open and understand" initiative.

This meant many iterations where I would head back into scripts and calcs which I had completed months prior. If I couldn't immediately understand my own code then I rewrote it. If something was extraneous, I cut it. Finally, after doing this for about a year, I sat down and created documentation about my own conventions. I then decided to release it to the public.

While not fully complete, what I've started is documentation for others to follow - and contribute to. I have no illusions that what I've documented will become the single standard - that's the dream world where we have "one" OS, "one" web browser and many other "one's" which makes it easy to do seemingly simple things, like create one css style sheet instead of 2 or 3, or be able to pick up a FileMaker solution and easily figure out what the heck is going on.

If collaborating on, and leveraging a set of standards, which frees you from the confusion of a database without order, sounds interesting, then this video should give you and idea of what I've started. My approach is one of openness. While some of what I've documented will stay the same, some of it will change based on input from the wealth of knowledge and experience which extends beyond my own. One final thing I found interesting while researching standards was the opening section of the Java Code Conventions document from 1997.

• 80% of the lifetime cost of a piece of software goes to maintenance.
• Hardly any software is maintained for its whole life by the original author.
• Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
• If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

Enjoy the video and if so compelled, join in. Let's create something useful that benefits those who adopt it!

When FileMaker 8 was released in 2005 it was a game changer for the world of FileMaker scripting. You could now pass data into scripts from buttons - added to already being able to access data from within the script. It wasn't long after its release that developers wanted to pass information to scripts in a more structured fashion. "Passing multiple parameters" is a common term in FileMaker development and there are many ways to accomplish it.

In 2006 I released a video about the topic of "Function Scripting". It was a very popular article which advanced the idea of using scripts as something similar to functions and treating them more like methods in object oriented languages.

I simply combined two different sets of custom functions from two very smart developers. Over the years, I've used the method almost exclusively for passing information into scripts. Recently, however, I've started to use an evolved method of passing information into scripts.

The method I'm now using, focuses a great deal on code readability and facilitates both strict and relaxed parameter requirements. The function is a multipurpose function which can be used in many areas of your FileMaker solution. In this video, I walk through the evolution, some of the other options you have available and why I've chosen to adopt this new method of passing parameters into scripts.