In a previous article, we chatted about FileMaker error codes and made a point to emphasize the importance of keeping our eyes open during development. We have to be ever vigilant within the obscure areas of our solutions where things might break. Sometimes, we have to push our solutions to the brink in the hopes of revealing a weakness that may have otherwise gone unnoticed. We also took a look at a few techniques for trapping errors and then organizing them so that we can deal with them appropriately. This post will explore a new tool that Claris gave us a few versions back called Set Error Logging. This tool allows us to take error trapping to a whole new height.
The Support Group Blog
The Claris FileMaker Platform makes it easy for us to develop functional custom applications. We can move data from repeating fields and manage and customize images in FileMaker applications. It's also relatively easy for us to identify errors, but we have to know how to organize and interpret FileMaker error codes. If we learn when and how to leverage specific tools that FileMaker provides to troubleshoot bugs within our apps, we can avoid issues and frustrations down the line.
Identifying and capturing errors within our FileMaker applications are an essential part of the development process and it can feel a bit like a roller coaster ride. When we create an app that makes our jobs easier, we want to make sure that it does the right things effectively and reliably. That's why having a solid understanding of the potential error codes we might encounter and how to resolve them successfully is so important. In this post, we'll deal with the highs and lows of fool-proofing our FileMaker apps by maneuvering through conventional errors and exploring some common places where bugs tend to crop up.
We've discussed some backup principles for our FileMaker applications, specifically, the when, what and where to protect the data within up our custom apps. Now we're going to cover the how. The on-premise Claris FileMaker Server product not only allows us to share our custom solutions with our coworkers and the world, but it also gives us a set of tools to protect our valuable data and workflows. We'll outline the use of these tools and how they connect to the decisions we make based on the principles we discussed in the previous post.
Claris FileMaker is a powerful tool for creating automated workflows; workflows that not only make our workplaces productive but also ensure accuracy and consistency within our business processes. When you think about it, each of our scripted workflows encapsulates a vital piece of our organization's tribal knowledge. FileMaker applications are typically created, extended and maintained by the very process experts that use them, which isn't usually the case with other software development platforms. So our FileMaker apps easily become a projector of our business goals and operations.
One of the many features that make FileMaker such a powerful and flexible tool is the Script Workspace. Scripts make it possible for you to manipulate and execute various actions on the data within your application. They help to maintain efficiency, consistency and accuracy by automating manual workflows. Keep in mind, FileMaker 18 added 11 more file-based script steps to our tool belts.
We frequently use scripts to find and sort records, generate reports and send emails. We've even shared ways to move data from repeating fields and to manage and customize images in FileMaker with scripts. Depending on the task, a script could be as simple as a single line of code or as complex as hundreds of lines of code. Building a script can be a bit intimidating at first, but FileMaker's low-code, step-by-step approach to building scripts makes the process pretty painless once you get the hang of it.
It might sound trivial, but naming conventions are significant factors when you're developing business applications. A systematic way of naming files, tables, fields, etc. provides a high level of organization, consistency and efficiency to both app developers and users. A good naming convention also allows an app to be easily adaptable, scalable and transferable throughout its useful life. These benefits all apply for apps developed within Claris’s FileMaker Platform.
If you're a user of a spreadsheet or any other program that displays information in tabular format, you're probably familiar with a quick sort technique. You can usually click a column header and the data within the column will automatically sort in some way. You can sort of (pun intended) do this within a table view layout in FileMaker as well, but it's not as simple as a click. You have to right-click on the header and navigate a Byzantine labyrinth of menu options before you get to what you hope is the expected result. Wouldn't it be nice if you could provide the typical user experience to yourself and your users within your custom FileMaker app? Well, you can...by naming a few fields/objects on your layout, creating a global variable or two and some buttons that run a script. But we're putting the cart before the horse; let's start at the beginning.
We've shown you how to add custom headers to a CSV file. Custom headers are useful, particularly for end users, because they provide intelligible header names when downloaded FileMaker files are opened in other applications. We developers don't always use intuitive field names when we're in the heat of custom app development. It's usually a bunch of geeky gibberish only the coder can understand. FileMaker 18 actually simplifies our custom header export process a bit, thanks to a few of the new script steps that this version offers.
Before we begin, it might be helpful to review our FileMaker 18 file-based script steps blog post, particularly the section that discusses how to read, write and manage external files. This will give you a good foundation before taking a look at this more advanced topic.
Image features are pretty common within FileMaker apps. We've had the ability to store images and other types of files in container fields for quite a while. Usually, we leverage that capability to build image modules for our clients. Having developed several of these myself, I can tell you that users generally want to be able to do at least three things:
- Save the images in FileMaker
- View a thumbnail of the image
- Customize the size of the image
Of course, there are different ways to accomplish these requirements efficiently.
Repeating fields have a long and somewhat controversial history in FileMaker. If you want to start a heated discussion with another FileMaker developer, start one about repeating fields! Some developers love them, some hate them and then there are some like me, who appreciate them as another tool in the belt to be used to accomplish functions that would be hard to do without them.
If you started building FileMaker applications from scratch in more recent versions of the product you may not be very familiar with repeating fields and probably have never used them. You may even have an understanding of what they are but have never found a need to use them. If you've been using FileMaker for a long time or have taken over a legacy solution, chances are you've had to deal with them.