Have you ever had a need for a value list that displayed a generated list of years in descending order? Have you ever had a client ask for a popup of dynamic characteristics or statuses in the order they are most often employed by the users?
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:
In part 1 we explored a particular type of value list: the field-based two-column variety, based on all values, and set to show values from the second column only…
…and today’s article assumes familiarity with that material. This time around we’re going to look at some challenges and issues that can arise when using filtered (a.k.a. “conditional”) field-based value lists, and propose some solutions to those challenges.
I don’t claim that any of the following is particularly original or brilliant, but I do a fair amount of team programming, and these issues come up over and over again.
In July and August we explored several esoteric value list techniques. This time around, and over the next few postings, we’re going to step back from the cutting edge, identify some common value list challenges, and propose some solutions to those challenges. A few thoughts before we begin:
- Some of the material in this series will be beginner-level; some will be either intermediate or advanced, depending on your point of view
- Value lists are subtle and multifaceted; to get them to do what we want, we sometimes have to move beyond the obvious
- As often happens in FileMaker, there are many ways to skin the cat
- I plan to explore only a few of these ways
- But will do so in microscopic detail
Now on to our first demo (Thinking About Value Lists, part 1 demo 1), which contains a table of employees with office sizes. Here it is in layout mode…
But first a bit of background. Prior to July 18, 2012, if anyone had told me you could base a value list on an unstored field, my response would have been something along the lines of…
- What app are you using? (Because it sure as heck ain’t FileMaker.)
- Why are you wasting my time with this nonsense?
- Is today April Fool’s Day?
- What are you smoking?
But then John Ahn showed this amazing Conditional Value List demo during the DevCon “Unconference” session devoted to ExecuteSQL (see previous posting), and to my way of thinking, the most intriguing part of session was only incidentally concerned with SQL, because John seemingly had achieved the impossible — a value list based on an unstored field.