ISO FileMaker Magazine

While recently crafting a new layout theme, which is a darn close replica of the iPad UI for FileMaker Go, I discovered a number of issues one should pay attention to for mobile development in FileMaker. The iPad and iPhone 4 are pretty snappy devices - although I'm still using the 3G iPhone (can you say "getting slower each day") for my phone. However, FileMaker Go suffers from a bit of a "lag" in the UI department. It's great that you can access your data, but doing this over a slow 3G connection is likely painful (I've personally only got the wi-fi iPad, so I've not tried).

The hype about the mobile market and FileMaker Go is warranted. I mean, it's really cool that all you have to do is buy a copy of FileMaker Go for the iPhone or iPad and you can be up and running with your database - uh, almost...

These mobile devices use a totally different method of interaction, and vary between the iPhone and iPad. Personally, my position on developing for any unique platform is that you break that platform out into its own file and simply access the data in a separate data file. The nuances of designing/developing for mobile versus the desktop client warrant some serious evaluations as to the validity of doing it all within one file.

So, without delay, I offer you 10 of my best lessons learned while developing this layout theme for the iPad. I think you'll find that some of them may be very eye-opening when it comes to how you deploy on a mobile device - Enjoy and HAPPY NEW YEAR!

Would you ever expect anything less from a father who is so proud of his brand new baby? Of course not!

So, I simply had to show you some more of my new baby in action. The good part is, the information is free.

Here's a collection of some free tips about making things happen within your FileMaker UI Design. Whether you're using the Theme Studio or not, you can really accomplish some nice UI design if you know how to fully leverage FileMaker's tool set.

Have some of your own tips? Leave them as comments on this article!

It's one of those somewhat trivial projects (or so you think) until you get down to the "nitty gritty" of making everything work.

"All we need to do..." is always WAY more complex than what's thought. So it make sense that storing data in the most efficient and usable manner would go without saying. However, time and time again, I see database files where the data is stored the "FileMaker easy way" and this just shouldn't be done.

There are those rare cases when you should make a value list with your common names such as "Kindergarten, 1st grade, 2nd grade, etc.". But, more often than not, you should be storing your data in a more optimized fashion. Making it work within the user interface is what becomes the issue of implementation.

This video presents the optimized and efficient manner of storing some of your checkbox and radio button data. It's a great lesson on how to really structure some complex stuff in a very easy fashion!

Errors, problems and troubles - Oh my! It seems as if more than half the coding done is for solving problems created by writing the code in the first place. Don't worry though, it happens to all of us. It's part of the coding process. You simply can't know all the variables.

You see, you're working in a known environment. The issues you fix are related to the problems which exist in your own computing environment. However, if you're putting something out there, you simply can't account for all possible issues. Not from the start.

Hopefully, at least on this issue, if you can learn from my lessons, I'll save you a ton of time. In my situation, with my Theme Studio product, it turns out that a good number of people using FileMaker do not use AutoUpdate, or at least have never had a reason to.

In FileMaker 9, FileMaker Inc. added a new shared extensions path for plugins. This shared extensions folder is where you can install a plugin and have it running for versions 9, 10 and 11. Here are the paths.

Windows XP:
C:\Documents and Settings\User Name\Local Settings\Application Data\FileMaker\Extensions

Windows Vista/7:
C:\Users\User Name\AppData\Local\FileMaker\Extensions

Mac OS X:
Macintosh HD/Users/User Name/Library/Application Support/FileMaker/Extensions

When trying to install a plugin, from a container, into this location, I was getting reports of errors and not being able to install the plugin. Silly OS messages would appear like "You don't have enough disk space.", etc.

There is where the topic of this video came in. Typically, I'm using a plugin to manipulate files and folders. I opt to use 360Work's ScriptMaster (of which there is a free version). The problem, however, if you haven't already figured it out, is that I can't us a plugin if it's not already installed yet. And I needed a folder in order to install the plugin - otherwise FileMaker was throwing an error.

So the question was, "How can I create a folder in order to install a plugin via AutoUpdate?"

The answer was to use the OS to create the folder. So here you have a video about using the OS in order to do all kinds of things. The example shown is that of working with folders, but it doesn't stop there.

If you understand the topic taught in this video then the limits to what you can do with FileMaker alone will expand SIGNIFICANTLY!

You hear the announcement about FileMaker 11 and you make a quick scan of the new features. You decide to investigate them as best you can, (because you have real work that needs to be done) and you tell yourself "I'll look into them later."

Time passes and you've yet to use a few of those new features. This is my story with QuickFind. I've long created my own version of QuickFind with a scripted process which takes input from a global field and executes a search across multiple fields - even creating multi-query searches. No big deal.

In fact, there's still a reason to do that, if you want to build upon a previous search. QuickFind does not store the last find such that Modify Last Find script step will pull up the criteria.

However, recently, I hacked up a quick file and needed to do some quick and dirty searching. It turns out that doing so is a dream with QuickFind. You don't even need the actual fields on a layout. You can use text labels, which hide themselves with conditional formatting, in order to supply QuickFind with the proper search fields. Turn the fields you don't want off with a checkbox (FileMaker sillily assumes you want to search all fields known to your database).

Throw a global text field on your layout, add a constrain here, an extend there and adding the feature to any FileMaker 11+ database is a no brainer. Just do it, it's way too easy. If you need more of the details then watching this video will certainly help you out!

On/Off checkboxes are wonderful things. While, in life, we often wish we had an on/off checkbox for certain people, it certainly is much easier within a database - and quicker to accomplish.

In fact, it's so easy, you can have an unlimited number of on/off checkboxes without ever having to write a single script. Yes, you heard it. No scripts.

"But wait?" you say, "I simply add my on/off checkbox to my layout. I didn't need any scripts in the first place." To answer, I say "Yes, but they probably aren't being stored as efficiently as they could be, and if they are, you're not following conventions which users are already use to, in particular, being able to to click the checkbox label as well as the checkbox."

So along comes this video about scriptless checkboxes and being able to select ranges of checkboxes within a list view. It presents the best options for checkbox storage, it allows you to limit the amount of database clutter and reduces the amount of time it takes to add them. Combine these all together and you wonder if you couldn't be doing it better than you are right now. Need to figure it all out? Watch this video and you'll soon know!

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!

There are certain things in FileMaker you do day in, day out. One of them seems to be the familiar "dialog dance" - where jumping down the dialog chain is a normal part of every day development.

FileMaker calculation code is almost always buried a few dialogs down. I seem to always be hunting for information about what I'm working with, whether it's the field name, the table occurrence name, the relationship I should use, value list, what have you.

So it goes without saying, we'd all like the development environment to be more fluid within FileMaker. FileMaker 11's addition of the Inspector palette was a nice big jump towards more helpful tools.

While the Relationship Graph could still use a ton of polish in the realm of organizational tools, there's enough already in the application for us to create some of our own helpful resources. Using tool tips, and some creative inspiration, we can inject some nice environmental information which helps us know what's going on with the database. Watch this video for a great tip which will help you prevent sloppy coding and having to open a few more of those embedded dialogs!

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!

Wow, if that isn't a mouthful! "Defensive coding with literal references". This likely wasn't even on your FileMaker radar. In fact, FileMaker takes care of so many things for you, it's easy to think your FileMaker solution will just run forever. Funny thing is, there still are FileMaker 5/6 solutions running to this day - I've seen them!

In the days prior to the .fp7 file format, it was actually quite hard to create your own solution errors outside of the possible errors which FileMaker already accounts for. Unless, it was something silly like deleting a layout entirely when it was used by multiple scripts.

However, with today's more powerful FileMaker, you can certainly create a solution which will break in a heartbeat. As you add more and more complexity, you also increase the potential for things that may break. Here's what I mean. You use a Go To Layout [] script step, and you select the option to go to a layout by name - via calculation code. You input the name of your layout as "Customer list". Three months down the road you rename that layout to "Customer filter list" because it now more appropriately identifies its application.

Guess what broke? Your code! While this example is likely easy to track down and fix, it's even better to build in some preventative checking for these types of situations. That's exactly what this video is about. Using a dedicated technique for making sure your literal references can be more easily fixed when, and if, they break.

The easiest fix is to catch the issue before you release or set up some type of notification. Here are just a few of the ways you can cause yourself some headaches using literal references.

• Go to Layout [ "some layout" ]
• Go to Object [ Object Name: "some object" ]
• Set Field By Name [ "literal field"; "some value" ]
• Select Window [ Name: "some window name"; Current file ]

These script steps all provide possible literal references, and you want to make sure you won't get in trouble with them! Fortunately, I have a great solution!