I began using FileMaker at the spry old age of FileMaker Pro 8, so I’ve never been through the trenches of using repeating fields to accomplish what can now be done with portals. However, repeating fields still have a variety of uses, and I’m happy to have them in my toolkit.
When I’m working with a repeating field, there are several questions I might ask of it, depending on the task at hand.
Here’s an interesting interface challenge we recently faced: A client needed to place text fields on a layout and fluidly choose which fields would be editable or read-only—the same field might exist in both editable and read-only state on the same layout.
Now, here’s the challenging bit: Each read-only field must have all the same capabilities of its editable cousins—users must be able to scroll, select, and copy text, and the field control must display all rich text formatting entered.
On vacation, waking up to a dreary Pennsylvania morning…
I found myself staring at the OS X Address Book and wondering, “how did they do this?” I couldn’t help compare this little application to the many FileMaker-based contact management solutions I have seen, and concluding, a bit sadly, Apple’s is nicer.
If you’re like most power FileMaker users, you’ve discovered that it’s a great tool for managing collections of things or for gathering disparate data sources for reporting. So you’ve probably wanted at some point to do one or more of these actions:
Get a list of files on your computer
Import a batch of files
Move files on your computer
Read the text of a file that doesn’t import correctly (e.g., HTML)
Neither I nor my client can anticipate every chart that the solution’s users might want to see. A user’s desire to view a high-level visual representation of their data can be spontaneous and idiosyncratic. This technique allows for the user to create an ad hoc chart, albeit within narrow parameters (i.e. the chart is simple, presents only counts of values, and is pre-formatted).
I recently needed to total up some records in a found set in a FileMaker solution, but I wanted to keep all the revisions within the scripts so that I could easily migrate the changes from the development system to production. This solution also already had quite a few “special case” calcs and fields, and I didn’t want to add any more clutter to the schema.
If you have a FileMaker system and you need to script the processing of adding or removing files on the server, the first problem you are going to come across is: how do I stop the server from a script?
You may already be familiar with the fmsadmin command. This is present on both Mac OS and Windows installs of FileMaker server. You can simply run the following command in Terminal to stop the server:
FileMaker 11 is here! Are you ready for the next generation of the world’s most widely used, easy-to-use database?
As Platinum members of the FileMaker Business Alliance and long-term beta testers with FileMaker, we’ve been testing the new version of FileMaker for a while now and wanted to share some of what we’ve learned.
Today we are making bBox, our toolbox of external functions for FileMaker, freely available to all FileMaker developers. Use it to extend the reach of your FileMaker solutions to resources outside of FileMaker by launching and communicating with other programs, utilizing the powerful commands built-in to Mac OS X, and easily creating, processing, and managing files.
In my last post, I described my preferred methodology for integrating Rails and FMP. In this post, I’ll discuss an alternative technique using FMP’s external SQL sources functionality. Since IANAFMPD (I am not a FileMaker Pro Developer), I’ll skip the implementation details and just cut to when it’s an appropriate solution.