One of the great things about FileMaker is its ability to not only create a PDF from a single “print job”, but to take a series of separate jobs and concatenate them into a PDF via the “Save Records As PDF [append]” feature, like so:
(The above code comes from PDF Catalog with Table of Contents, which appeared on this site last year.) Basically, anything you can print from FileMaker, you can instead output as a PDF.
But what if you have existing multipage PDFs stored in container fields, and want to combine them into a larger PDF? This is something FileMaker cannot do natively. Recently I had a need to do just this, and happened to mention it to Jon Rosen at ErgoSoma, who suggested I take a look at a cross-platform utility called PDFtk Server.
If you build multi-user business systems, you may have had a need at one time or another to temporarily “lock” a process, so that only one user at a time can perform it. A typical drawback to most process locking approaches is that the lock does not automatically clear if the user who locked the process crashes or otherwise bails out of the system abnormally.
Well, I have some good news: Bob Gossom of Absolute Advantage has come up with a very clever, and well-documented, self-clearing process lock technique, which I’m pleased to share here with his permission.
Note: A special thanks to Jason DeLooze for sharing this technique, which neatly remedies a small, but vexing, annoyance.
Demo file: Show-Hide-Formatting-Bar.zip
Have you ever wanted to have a script toggle the Formatting Bar on/off in browse mode? If so, you will discover that FileMaker does not provide a “Show/Hide Formatting Bar” script step.
Picking up where we left off in part 1, today we’re going to take a look at examples 2 through 6 in the Virtual List Charts demo file (the demo has been updated since part 1, so I recommend downloading a fresh copy).
We covered example 1 and most of the general concepts last time, so today we’re mainly going to touch on specific points of interest, but to briefly recap… Continue reading
Update 5 May 2014: article and demo have been updated as per observations by Jeremy Bante in the comments section.
This weekend I threw together a Unicode utility file (unicode-characters.zip). It takes the values 1 through 65535 and converts them into Unicode symbols, and makes it easy to copy characters and values into the clipboard.
(The original version of the demo had 99999 records, but as pointed out by Jeremy in the comments section below, the range 65537 – 99999 is a repeat of the range 1 – 34463, with 65536 being a special case.)
Any value over 99999 the Char function will interpret as multiple characters, and bear in mind that multiple values are interpreted a) from right to left, and b) in five digit blocks with leading zeros, except the leftmost one will not have leading zeros.
Recently there has been discussion in the FileMaker community regarding a known problem with live development (i.e., modifying database schema while other users are connected to the system). The problem is that under certain circumstances, the “New Record” command and script step will fail.
The aim of this article is to identify some specific circumstances under which New Record will fail, and also identify some specific circumstances under which it will *not* fail, and is based on a series of tests conducted using FMS 13v1 and a couple clients running FMP Advanced 13v3.
Disclaimer: These are preliminary findings and do not claim to be exhaustive or conclusive. If you are doing live development, you should test for yourself and draw your own conclusions.
Methodology: A system with two tables, Sales and Employees, was used. For all tests, the developer opened Manage Database and then did something (or in the case of the first test, nothing), but then did not click OK — instead the Manage Database dialog was left open. In no case was the “OK” button clicked.
Today we’re going to look at applying the virtual list technique to FileMaker charting with the goal of producing a reusable chart “object”, or rather, a series of chart objects. We’ll need more than one because while certain attributes (e.g., chart title) can be set programmatically, others, including type (e.g., column or line), must be hard-coded into the chart object.
We’ve already explored Bruce Robertson’s virtual list on this site a number of times, but briefly, you create a utility table in your solution to facilitate non-standard viewing, reporting, etc., and pre-populate it with “more records than you’ll ever need”. The records in this table will derive their data “virtually”, by parsing it from an array — typically one or more $$variables.
Well it turns out the technique can be applied to charting as well, and today we have a demo file, Virtual List Charts, that contains six examples: three for Web Visits…
Thank you to the folks at FMDiSC (FileMaker Developers in Southern California) for allowing me to present this past Friday on the topics of Summary Lists and Virtual List Charts. Here are links to files we looked at during the presentation, as well as relevant blog entries and xmChart links.
In part 1, we looked at a new way to count unique entries in a sub-summary report based on an arbitrary found set of sales data. To avoid redundant explanation, this article will assume the reader is familiar with part 1, but in a nutshell…
1. we used a pair of FM 13 summary list fields
2. to create found-set-aware multiline keys
3. which we related to special purpose table occurrences
4. which provided the basis for related value lists of salespeople
5. the ValueListItems function allowed us to grab lists of unique salespeople
6. and the ValueCount function allowed us to count them
The demo in part 1 was based on a single “flat table” of data. Today we’re going to unflatten that table, and see how the technique can be applied to a properly normalized system, i.e., with separate tables for Sales, People and Zones, related like so…
Several recent postings on this blog have offered variations on a theme: using the new-in-13 summary list field type as the basis for a multiline relational key. The net effect is to produce a relationship that is found-set-aware. (If you aren’t familiar with summary lists, you can read about them here.)
Last week we looked at basing a value list on one of these “summary list relationships”, to facilitate counting unique values within the current found set…
…and today we have a demo file, FM-13-Count-Unique-v1, that extends the concept to sub-summary reporting.