Recently, in a virtual list report, I had a need to sort on rep number 2 of a repeating field called cell_text_r.
FileMaker does not offer an obvious way to script a sort on a field rep > 1, and I had worked around the problem in the past by…
A. Defining some special non-repeating fields in my virtual list table like so
[Note 1: as always a huge thank you to Bruce Robertson, for inventing virtual list, and for many other contributions to the FM community over the years.]
[Note 2: the following assumes the reader is familiar with basic concepts presented in Virtual List Reporting, part 1.]
This is a follow up article to document new material from my recent FM-DiSC presentation: Virtual List on Steroids. The presentation was intended for developers who are (at least) somewhat familiar with virtual list, but for those not actively using virtual list, I decided to begin with a demonstration of “the problem” (or one of the problems at any rate) that virtual list was invented to solve.
Demo file: scrolling-the-unscrollable-v2.zip
Howard Schlossberg’s presentation on popovers (FileMaker 13 Popovers) has inspired me on multiple occasions… a favorite takeaway is the idea that you can have a scrolling check box set within a popover. Continue reading
Editor’s note: Once again it is an honor and a privilege to present an in-depth guest article written by Beverly Voth.
This is a follow-up to the User-Friendly Excel Exports series by Kevin Frank, but using an XML export along with various XSLT to give you .csv or .xls (for Excel). The first demo is a quick export (to CSV – comma-separated values) using an XSLT to help explain the relationship with FileMaker Pro XML export. How an XSLT style sheet reads that data to transform it into another text format (.csv or .xls) is also explained throughout the article and in comments within the XSLT. The demos will get increasingly more complex, but ultimately more “user-friendly”.
Demo file: Excel-Exports-using-XML-and-XSLT.zip
Note: Leaner does not always mean faster, especially if record counts will be large… in which case I would recommend going with the approach discussed in part 2.
[3 Jan 2018: demo updated to version 3.2 as per Jens Rasmussen’s comment below.]
[2 Nov 2017: demo updated to version 3.1 as per my exchange with Jonathan Mickelson in the comments section below.]
I thought after part 2 that this technique had been thoroughly discussed and dissected, but Geoff Gerhard of Creative Solutions writes to point out that, if the goal is to have as few moving parts as possible, the table occurrence (TO) count can be further reduced, from four to three…
…and he has provided a demo file which I am sharing with his permission.
Demo file: reciprocal-linkage-GGv3.2.zip
29 June 2018: I have taken this article offline as it has been completely superseded by this one: Virtual List Reporting with JSON Arrays.
Update 29 June 2018: see Virtual List Reporting with JSON Arrays for updated thoughts on this topic.
Today we’re going to look at an alternative approach to the multi-window VLR technique we examined last month in Virtual List Reporting part 3, utilizing and extending techniques introduced in last month’s JSON + Virtual List. To avoid needless repetition, today’s article will assume the reader is familiar with that material.
Demo files: vlr-plus-json-v1 and vlr-plus-json-v2
As you may recall from VLR Part 3, we have a system that allows us to spawn as many separate reports as we wish (each in its own browse mode window) and sort each report independently via clickable column headings. Continue reading
31 July 2017: As per my exchange with Beverly Voth in the comments section, the date encoding technique used here is strictly intended for situations where FileMaker will both produce AND consume the JSON.
Demo file: json-plus-virtual-list-part-2.zip
This is a short follow-up to part 1, to demonstrate an alternative idea re: JSON date encoding. As you may recall, JSON does not have a “date” type, and one of our goals is to encode and decode JSON dates in a region-agnostic manner (e.g., encode in a region where MM/DD/YYYY is the default, but then decode in a region where DD/MM/YYYY is the default).
To accomplish this goal, in part 1, we wrapped our FileMaker dates inside a GetAsNumber function when pushing them to JSON so they looked like this:
