Last time we looked at several summary reporting tricks, including a conditional subsummary (when an item’s Status is “Scheduled” it will have a value in the Substatus field — otherwise Substatus will be blank). The challenge was to generate a summary report showing Substatus only where appropriate, without seeing any annoying empty gray rows beneath Pending, Cancelled or Completed. And last week’s report worked fine… in preview mode.
One of the best ways to learn about a particular FileMaker feature or behavior is to build a demo. You might build one in response to a client request, or to try to answer a question somone has asked, or just to see what happens. At any rate, today we’re going to look at three demos, each of which explores some aspect of summary reporting. For reasons of backward compatibility today’s demos are in .fp7 format, but you can convert them to .fmp12 format if you are so inclined.
What these three demos have in common is multiple sub-summary parts on reporting layouts… so what you see on the report depends on how you sort it.
Well, we’ve reached part 4 in this series that has been going on in fits and starts since September, and we have just one demo file today: Thinking About Value Lists, part 4
Welcome to the third installment in this series. We’ve been exploring various issues and behaviors in connection with 2-column value lists (VL’s), and today we’re going to look at, and propose a work around for, an issue with filtered value lists in Find mode.
All of today’s demo files feature a basic expense submission system, with each portal row representing a receipt that the submitter would like to be reimbursed for. Here it is in Browse mode:
And here’s the Relationships Graph:
The other day I had a question about some nuance involving script triggers. The details of that particular question aren’t important, but I recalled that when script triggers were first introduced, Wim Decorte had produced a detailed, color-coded reference.
I wondered if he had updated it for FM 12, and it turns out that he has, and with his permission I am sharing it here. There are actually two files in today’s download (Wim Decorte FM 12 Trigger Reference): the four page PDF reference, and a FM 12 file demonstrating the firing order of the various triggers.
There is a wealth of information to be gleaned from these two files, and I encourage you to download them and check them out. And of course if you find any mistakes or have any trigger-related observations to share, I hope you’ll post a comment here.
Note: even if you are sticking with FM 10 or FM 11 for the time being, if you use script triggers, the PDF in today’s download contains much that you will find relevant (hence my categorization of this post as “Version: FM 10 or later”).
A few months ago I mentioned “dwindling value lists” in passing, and said I would do a proper article on them at some point in the future. Well, then FM 12 was released and I went on an ExecuteSQL binge, so I’m just now getting around to honoring my promise.
Dwindling Value Lists (DVLs) are value lists that shrink up, by removing individual list items as they are selected. They can come in very handy when you need to schedule resources and want to prevent double booking. This example comes from one of today’s demo files, Dwindling Value Lists, and shows how a DVL might be used to schedule employees for a work shift.
Essentially, a DVL is a filtered value list that updates in real time (or something very close to real time), and this is done by building a multiline key of selected values, and then filtering the VL to only show remaining eligible values. Continue reading “Dwindling Value Lists, part 1”
Ever since I posted part 2 of this series, I’ve been torn between, on the one hand, wanting to move on to other topics, and on the other, the realization that I wasn’t quite done with this one yet. So, here is what I expect will be my final posting, and final demo (dynamic list sorting, v3 rev5), on this subject.
Thus far, we’ve looked at various methods to facilitate dynamic list sorting (by “dynamic” I mean that the field to be sorted is determined programatically). Most of these methods use two fields — one of them uses four — and you can see them all in part 2.
But in the back of my mind has been the knowledge that Ugo Di Luca pulled this off with a single field back in 2004 (EasySort.fp7, shared by permission of the author, and previously discussed last April in an article entitled Portal Sorting, pt 3).
Well, I thought I’d said everything I had to say on this subject, but yesterday afternoon I noticed a glaring omission in part 1’s demo — what happens if the user manually unsorts the found set?
The sort indicator doesn’t disappear the way a good little sort indicator should. Fortunately this is easily remedied, thanks to the Get(SortState) function. Continue reading “Easy Sorting of List Views, part 2”
Earlier this year, I posted a three-part series on Portal Sorting, and part 2 focused on dynamically sorting a portal when a column heading was clicked. Well, with just a few tweaks, this technique can be applied to dynamic sorting of found sets, and of course the most likely place to employ something like this would be on a list view.
I should note that on very large found sets, sorts using this technique can be noticeably slower than traditional “hard-coded” scripted sorts. (Performance is fine with normal found set sizes.) The benefit of using this technique, is that a new field can be added to a layout and sort-enabled in about 60 seconds without touching the script itself.
When you consider how easily most common reporting tasks are accomplished in FileMaker Pro, the lack of a built in, clear cut method to count unique values within a given found set seems a bit surprising. But where there’s a will, there’s a way, and in part 1 we looked at a method that required the found set be sorted. Well I have some good news: today’s demo (Count Unique – Three Variations, 6.4 Mb) has no sorting requirement.
Here we have a flat file (single table) of contact information. For any given found set, the primary key (ID) will of course be unique, but each of the other fields will potentially contain duplicates, and we want to be able to quickly count the unique values without having to first sort the found set.
The basic approach can be summarized in a few words: Continue reading “Unique Records Revisited, part 2”