Earlier this month I was contacted by a DevCon presenter asking permission to include some slides from my eleven-year old anchor/buoy materials as part of his presentation. I said I’d be honored, but then added, “You might mention that I haven’t used A/B on a new project in about eight years.” He asked what system I was using instead, and a number of other colleagues have wondered as well, which brings us to the topic of today’s article.
A while back my youngest son, who is an avid Go player, asked me, “Is it true there are more possible Go games than there are atoms in the universe?”
“Absolutely,” I replied, “Let’s fire up FileMaker Pro and prove it.” (I wasn’t about to let a rare teachable moment slip by.) “If memory serves, the number of atoms in the universe is estimated be roughly 10^80. Since a Go board is 19 by 19, in theory there are 361 possible first moves (19^2), followed by 360 possible second moves for each of those 361 first moves, followed by 359 possible third moves for each of the 360 possible second moves, and so on. Therefore the total number of moves can be calculated as 361 x 360 x 359… x 1, or, more simply, 361! (i.e., 361 factorial).” Continue reading →
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
Editor’s note: Today it’s my pleasure to present a guest article written by Beverly Voth. Like many other developers, I have enjoyed and benefitted from her ongoing contributions to the FileMaker community.
I do a lot of text manipulation for EDI (Electronic data interchange – http://en.wikipedia.org/wiki/Electronic_data_interchange) and plain text exports with fixed-width field data. Some varieties of EDI use XML, but this article is about plain text. EDI may or may not use the fixed-width format. Fixed-width reports may or may not use delimiters and various “padding” characters.
I created two FileMaker custom functions to help me calculate fixed-width and EDI text for export, and if you wish, you can follow along in today’s demo file, Fixed Width EDI.
In October 2011 I posted a simple backup script that has made my development life easier, but of course that version was for .fp7 files only (the release of FM 12 being six months in the future), and when I began converting files to FileMaker 12, I realized that the backup script was not intelligently rolling with the changes. So recently I modified the script to accommodate both .fp7 and .fmp12 files, and also to be more flexible with regards to separators within the backup file name, e.g.,
Rather than repeatedly referring the reader back to the earlier article, I have “deprecated” the prior one and reproduced it here with appropriate changes, and have also updated the demo file (see below). Continue reading →