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.
Has this ever happened to you? You have a number of identically named fields in two different tables…
…but when you copy one of those fields from a layout based on the first table…
… and paste it onto a layout based on the second one…
…the result is not what you might have wished for.
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 “Fun with Factorials”
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:
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…
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 “A Simple Backup Script, revisited”
The other day someone asked a question on the FMP Experts list about plotting a driving route in Google Maps using FileMaker data.
Mark Rubenstein posted a simple solution, and my reactions were, in this order: “No way, it can’t possibly be this easy; I should build a demo (google-route-mapping) to find out; wow, it really works… hey, I wonder if he’d be okay with me posting this on FileMaker Hacks?” Continue reading “Google Route Mapping, part 1”
Note: FileMaker 12, released a few months after this article was written, introduced a “Find Matching Records” step, effectively eliminating the need for the techniques explored below (except for the section on case-sensitive searching).
Have you ever right-clicked into a field (or Ctrl-clicked if on a Mac) and chosen Find Matching Records? It works remarkably well, but oddly enough, there is no scripted equivalent for this command.
Of course if we do a Find Matching Records and then invoke Modify Last Find…
…we can see what FileMaker is doing behind the scenes. Continue reading “Locating Matching Records, part 2”
Note: FileMaker 12, released a few months after this article was written, introduced a “Find Matching Records” step, effectively eliminating the need for the techniques explored below.
Sometimes a seemingly-simple FileMaker challenge turns out to be more nuanced and educational than first impressions might indicate. This happened recently when I was asked to help make a scripted search behave properly. Most of the time, the existing routine worked correctly, but on certain records it would fail.
The challenge: Click a button to find all records with the same Note text as the current record.
No problem — how hard could that be? Any competent FileMaker developer can do this in his or her sleep, right? Well sometimes properly defining the problem turns out to be half the battle. Later, after the smoke had cleared, I built a demo to explore various approaches one might take…
…and we’ll get to that in a minute, but right now let’s look at the original script and the problem, or rather, series of problems, as they initially unfolded. Continue reading “Locating Matching Records, part 1”
