So here, at long last, is the solution:

mebeliLet (
[
NewSubSummary =( GetNthRecord ( MyTable::MyKeyField ; Get(RecordNumber)-1) <> MyTable::MyKeyField ); //Test if record is the start of a new subsummary. MyKeyField is the sort field for my subsummary part.

$on = $val; // $on will always be whatever $val was last
$val = If (NewSubSummary; If ( $val = 1;"" ; 1) ) // switch the value of val
];
$on // if $on=1, then apply the conditional format

)

[edit:] Or, in much simpler terms:

Let (
[
$b = If ($b ;"" ;1 )
];
$b
)

To me, the interesting thing here is the way that these variable expressions are handled by FileMaker. First of all, the conditional formatting seems to get evaluated, as one might expect, from top to bottom of the page, allowing you to use variables to keep track of formatting decisions that were made earlier on the page, or even on previous pages. It seems there should be some much cooler implications of this, like multiple title headers and pseudo-headers (don’t know what I mean by that? Neither do I…). The other interesting thing is that the variables here are local variables, but they’re kept active while the whole page is rendered by preview mode, which is what allows me to make reference to the last evaluation of $val and produce the alternating effect (yeah, I know I could just as easily use global variables, but it’s handy to know I don’t have to)

The reason that this gave me a checkerboard on the first try:

was because I had placed the formula on a repeating field, meaning that each conditional format formula was evaluated for each repetition, left-to-right. Once I placed the calc on a regular field, the checkerboard was gone and I had nice alternating rows.

————-

EDIT: This post got hosed somehow, and everything beyond the part where I refer to myself as an idiot was erased. I can’t remember what was idiotic about my original conditional formatting in this case (if I weren’t such an idiot, I’d probably remember). In any case, below is a reprise of the brain teaser:

———–

Each line in Edoshin’s crosstab technique is basically a repeating summary field based on a repeating summary calc. My goal was to get each one of these repeating fields to alternate its background fill. Using any kind of Mod-based calculation based on record number was going to fail, since these fields are on a subsummary, and there’s no way to predict how many records correspond to each subsummary part.

Taking a purely throw-rocks-at-it-until-it-stops-moving approach, I opened up the conditional formatting dialog on that repeating summary field, and hammered out a calculation. I was astounded, when I went back to preview mode, to see this:

My conditional formatting calc had inadvertently produced a checkerboard pattern. I realized, shortly thereafter, that by placing the same calc on a regular field, rather than a repeating field, I could get the alternating pattern as I desired:

The brain teaser challenge, before it got erased, was to figure out what sort of calculation could yield this effect on a subsummary part. The reward, if I recall correctly, was a signed copy of my memoir.

To the left is an example of what I mean. This effect can’t be achieved with portals (as far as I know). In this example, the canonical approach would be to construct a layout based on the invoice line items. However, doing so would make it impossible for me to put in the text element down the right side, or to incorporate related data from multiple tables.

To solve the problem, I create repeating calc fields in the invoice table and define them to refer to specific related records, depending on the repetition. For example:
 

Now, although FM 9 didn’t fulfill my wish of making this technique obsolete, it did offer a fix for one of the shortcomings of the technique – alternate row shading. To achieve this, make sure one of your pseudoportal fields extends the width of the whole set (usually, I just use the first field). Set conditional formatting on it for the color you want using this formula:

http://www.petervinogradov.com/TechniqueFiles/PV_PseudoPortals.zip 

The file also includes some fun CFs and examples for automatically balancing multi-column pseudoportals.

Yes, it isn’t exactly the feature I had in mind. I would have preferred to have full-blown access to all object properties and a way to program them using the calculation engine. But, Conditional Formatting gets me very close.

Here are a couple of basic highlighting patterns solved using CF.

1. Highlighting a Focused Field

There was quite a bit of buzz about Andy Lecates’ DevCon 2007 session where he showed off this active-field highlighting in his demo app. Andy noted that he was almost embarrassed to tell people that the formula behind this technique was literally a “1″. This puzzled me a bit so I decided to reproduce the technique. I have been told the credit for discovering this should properly be attributed to Chad Novotony of The Support Group. Kudos, Chad; it is really quite brilliant in its simplicity.

You can download the example file below and check out the conditional format properties of the fields shown.

The secret sauce behind this technique is to fill the fields with your highlight color of choice before you even open up the conditional formatting dialog box. I know this sounds completely backwards but the technique is based on the principle that a field object’s conditional formating expression isn’t evaluated when your cursor is sitting in it. So, when we enter the field, its CF stops working and the field defaults to its default fill color. So, the only thing left to do now is to make CF turn the fields white when I am not in it, which is to say, always make it white all the time. The formula for that? You guess it, “1″.

I know, I know…who would have thunk it? Kudos to Chad for this gem and to Andy Lecates for making it public.

2. Portal Row Highlighting

This next example is a bit more straightforward. We want to select a portal row and highlight it. Do accomplish this, you need two basic components, (i) an object to serve as the base CF highlight element, and ii) a script to trip the highlight. Here’s picture of the pieces before assembly…

The conditionally formatted object in this case is just a regular button set to turn blue if the value in a global variable, $$selected matches its row id. Next, make a script to set the $$selected global variable with the portal row’s record id. After that, bind that script to a “select” button inside the portal row and presto, portal row highlight without adding even one extra field!

Get the example file, conditional formatting example 1 to check this out yourself.

Cheers,

Ernest Koe
The Proof Group LLC

My own tactics for getting to my destination on the RG have traditionally resembled those of the early explorers:

• Stay near land and in sight of known landmarks.
• Make sure you know which way is north
• Have an up-to-date map
• bring plenty of oranges.
• Beware the twisted squid (a prehistoric throwback to ancient times known to trap sailors and drive them mad)

Of course, most developers understand that you can just key ahead to the right table. The only problem is that if, like me, you tend to prefix the daylights out of your TOs (AR__PPPL_MISC__NW_TC_BS_BFD_PrsPhoneDetail), then keying ahead starts to break down as soon as you hit your first underscore. Enter the lighthouse:

The lighthouse (shown here in pink) is just a table occurrence of an out-of-the-way table ( PS: You can just as easily do a lighthouse with a text box, but I like the single-line quality of a TO). In my case, I prefix these with a simple “z” and then a name for the particular constellation of TOs that I want to be able to target. In this case, a TO that handles the design of a scheduling function in my solution can be reached by simply typing “zsche…”. Note that when you key to your lighthouse, it will end up at the bottom right of your screen, so place it at the southeast end of your TOs.

Ahoy.

As a fulltime educator, there’s never any shortage of new and exciting projects to inspire me and capture my interest. As an FM developer, though, it can sometimes be a bit of a stretch. Even new releases of FileMaker (like that‘ll happen any time soon…) can be a melancholy blend of “gee whiz” moments and feature request letdowns (”what?! They didn’t include facial recognition on container fields?! Damnit, I’ve been asking for that since version 4!”). Fortunately, we can sometimes count on our clients to throw something fun our way.

Recently, a client asked me if we could integrate barcode scanning into their solution. It was a simple problem – set up a workstation so that the user could scan items off a catalog and have them end up in a proposal. For me though, I have to confess a little hesitation. As far as I was concerned, barcodes are for the big boys like Walmart and my public library. Why couldn’t my client just get by with the FileMaker value lists I had painstakingly set up for them (My specialty, the “item selection club sandwich”, stacked 12 deep with key-based dropdowns, masking popup menus, scriptevent plain entry, type-aheads, conditional container fields, mayonnaise, etc.). Anyway, I’d heard of barcodes, and understood the concept, so I said what the heck.

After shopping a bit, I found a scanner, ordered it and set about reading the Wikipedia entries on barcode symbologies. When I awoke three days later, the scanner had arrived (Symbol LS2208). I recommend this unit, but if you buy it, don’t order the “multi-interface” version unless you have some clue how to make the phone-jack-looking “multi-interface” end of the cable fit into your computer. The USB version, on the other hand, is really cool, and it was only a matter of seconds before I was scanning everything in my office and marveling at the little numbers getting magically typed into notepad.

If you’re integrating barcode scanning into a solution for the first time, and are simple-minded, be sure to plan for this phase of idiotic wonder, as it can be time-consuming. If you choose to bill your clients for it, then let me save them some money and share my research notes on this phase:

• You can’t draw working barcodes freehand. Don’t try.
• You can’t scan a barcode off the screen unless you own a CCD scanner
• The characters printed under the barcodes on stuff you own are exactly what the barcode says. There are no surprises or hidden messages.
• For father’s day, get your father a t-shirt with a barcode that represents the string “A55FACE”. It will amuse him at the supermarket self checkout.

With this research out of the way, I began to think about how to integrate my scanner with FileMaker. In it’s simplest form, you could click into a field, scan a barcode, and have that code appear in the field. Time-saving and cool, but it still falls well short of the kind of functionality your local grocer takes for granted. Ideally, you want each scan to trigger a script, and you want that script to take the contents of your scan and deliver it to the right place, and you want to be able to do everything without going back to your keyboard or moving your mouse. In fact, if you could do it without looking at the screen, that would be an even bigger bonus.

Possibly the simplest approach (other than the lame one described previously) would be to have a big global field to collect your scans, along with a button to parse the collected scans when you’re all done. To do this, though, you need a way for your scans to separate with carriage returns. Enter the world of ADF (stands for: awesome dynamic fun – look it up) rules, which are little macros that you can teach your scanner to perform every time it scans something. Luckily the LS2208 Quickstart Guide comes with a series of three barcodes just for this purpose. Scan them in order, and magically, your scanner will insert a carriage return after every scan.

While I had considered this approach briefly, it felt a bit cheap and it didn’t provide the user enough feedback to let them know what they were scanning (a field full of ID codes isn’t very friendly). So, I cracked open the 400 page PDF that comes with the LS2208 and started learning more about ADF. From my initial read, it looked like the way to teach my scanner to do fancy scanner tricks was to jump around the 400-page PDF, work out the proper series of steps, represented as barcodes, and scan them in exactly the right order (and of course, from my research in the idiotic wonder phase, I knew I would have to do a lot of printing since I couldn’t scan off the screen). So while I found all these magic ADF barcodes to be really neat, in theory, I began to wonder whether the people at Symbol (Motorola) might not have bothered to write some software to handle all of this. Digging around in my LS2208 CD, I discovered exactly that, a little utility called 123Scan. I ran it, and spent an hour and a half trying to get it to talk to my scanner. A quick trip to the PDF let me know that it would only work if my scanner was connected by RS232 serial cable. I was about to resign myself to hours of tedious flipping through the PDF when I discovered that I could use 123Scan to generate a script of ADF barcodes and send them to my printer. Happy Day.

So, first order of business was to get FileMaker to execute a script when a barcode got scanned. What I figured I could do was use the ADF rules to prepend a keyboard shortcut to the front of each scan. I really wanted something out-of-the-way, like CTRL+ALT+SHIFT+6, but it didn’t seem like ADF could get that fancy. CTRL+6 would have to do. In FileMaker, I set up a custom menu for my script and gave it the CTRL+6 shortcut.

My next concern was the time lag between launching the script and handling the remaining data. I didn’t want the barcode data stream to get lost while FileMaker was trying to get a script in gear. Fortunately, ADF allows you to set pauses, so I did (with a little experimenting, it seemed like 0.4 seconds was as short as I could make it and still have it be reliable).

Finally, I knew I would need an enter key (the keypad variety, not the keyboard version), and a beep at the end to let the user know the scanner was ready to go again.

With all of that set up in 123Scan I printed up the ADF barcode instruction series, scanned it into my LS2208 and behold, it worked. What followed, of course, was another hour or so of Idiotic Wonder – “Does it really work? Wow. What happens if I scan this? Wow. What about this? Wow. What about from 2 feet away? Wow. Etc.”

Of course, you do have to think about what you want your FM script to do with its data stream. After some experimenting, I settled on having it invoke a custom dialog with the title “Gathering Barcode” and a single global variable input field. With the “Enter” key suffixed by ADF rules, this dialog only flashes for a second and I kind of like the visual feedback. With this barcode collected, I could safely process the input, manage context, error trap, etc.

Another gotcha is the possibility of unfriendly barcodes. Suppose someone accidentally (read: inquisitively) scans their gym pass. In my case, I knew all the “good” barcodes would represent ID numbers with the same common two-letter prefix. It took some fiddling, but I was able to organize my ADF rules so that barcodes without the prefix would just generate a beep and pass nothing to the computer.

Finally, what about generating the barcodes themselves? My client assures me that they have an office supply vendor who will generate sequential barcode stickers for all items going forward, but I also wanted the option of generating the occasional set of labels in-house. Working together, Google and I turned up this handy tool: http://www.barcodemill.com/index.php Which also includes a neat little image tool you could work into a web viewer: http://www.barcodemill.com/tech/index.php?load=/tech/install/millfree.php (I’m not sure the operator would look favorably on an industrial-strength application of this – they do have a commercial version – but I imagine the occasional lookup wouldn’t hurt). If someone out there knows of a better free barcode generator, please post below.

As for symbology, I settled on Code 128. It supports a full ASCII set and is relatively compact. The next phase of this project is going to involve a mobile solution for walking around a showroom floor and collecting items to upload later. I’ve set aside a full two days for idiotic wonder when that hardware comes in…

In an effort to avoid a similar fate, I recently took a week of exile from work (pretty fancy term for “vacation”, no?) and went to a location where the only internet access was dialup. Before I left, I opened my “trip packing” database, checked off the boxes for “cold, relaxing, sun” (I was going to Canada), unchecked the box for “work” and set the “willingness to smell” field to a value of 9 (out of 10). I printed the resulting packing list and closed FileMaker for a whole 7 days, possibly the longest for me in three years.

That gap gave me some time to reflect on a number of nagging personal questions. For example: “Do I want to quit my day job and be a fulltime consultant?” or “Which will ultimately be a bigger letdown: iPhone, FM9 or the Heroes finale?” One such reflection was on the issue of my various FM workarounds and techniques.

I am a big admirer of developers who spit out technique files and custom functions whose utility are matched only by the simplicity and elegance of their approach. “What’s that? You want self-documenting contextual help menus on all your layouts. Why presto! Here’s a two line startup script that will do exactly that…etc.”

My own techniques, by contrast, tend to address the most oddball situations with the most epic ensemble of steps and components. Earlier this year, for example, a school I consult for wanted to revamp their student reports in the lower grades. They wanted space for subject narratives along with checklist items tailored to specific subjects and grade levels. This was familiar turf for me, so I wasn’t sweating it… yet. As we got into it, though, it turned out the school really wanted to be able to display the checklist items in multiple, balanced columns, they wanted individual items to be able to wrap to multiple lines, and they wanted absolutely no whitespace. The issues here may be obvious, but I’ll spell them out: the checklist items exist in a related table, which means I could either build the layout with portals (and kiss the word-wrapping/sliding goodbye) or build the layout on the checklist items table with subsummaries for all the report parts (and kiss the balanced columns goodbye). I have taken both approaches for other clients and projects.

Now, these are longtime FileMaker users, and I had been clear with them that they may have to live with certain limitations, but when it comes down to it, I hate having to break it to a client that between me and FileMaker, someone’s about to come up short. So, I gave them my usual “let me play with it and see what I can do” and then set about finding a workaround. After a day or so, I worked out a way to use repeating calc fields to draw in the related data, and these behaved miraculously well in terms of sliding (btw – anyone who feels like dissing repeating fields really needs to keep it down until FileMaker dramatically improves their print offerings). If anyone is curious about this technique, I’ve put a file here: http://petervinogradov.com/TechniqueFiles/PV_PseudoPortals.zip )

To be clear, this method is far from ideal. When I generate a student report from my location, I can actually hear their server whining about it from 100 miles away. Still, the client was happy and I was just left having to figure out how I wanted to bill it. See, I’m a big fan of spiral development, but when things like this come up my spirals tend to take on a shape that would do Salvador Dali proud. As much as I don’t like telling clients that something can’t be done, it feels almost as bad telling a client that something seemingly trivial took an ungodly number of hours to accomplish. But I guess that’s fodder for a different essay.

I’ve hacked my way through many workarounds like this, and usually, I get to a point where I start to wonder whether to keep going or whether it’s time to cut my losses and turn back. Just how many plug-ins, custom functions, scripts and “utility tables” does it take to bring me to that point? Well that depends on a lot of factors, including client personality, sleep, caffeine levels, and that ubiquitous parameter, “willingness to smell”.

For a while now, I’ve been dabbling with “session model” architecture, which is basically where you have all your action take place in a “sessions” table, and hook out to your database by setting various key fields. While I won’t go into detail about my specific approach (the good people at DevCon certainly didn’t think I should…grumble…grumble…didn’t want to go to their stupid conference anyway…etc. ), I will say that it has a certain style that appeals to me and has enough compelling advantages that I decided to take the plunge and apply it to a number of big projects.

Now, unlike the sliding portal workaround, which has a discernable plug that can be pulled at any time, the decision to build an entire interface around a non-standard architecture required a pretty big leap of faith and a commitment to live with whatever limitations emerge. For one thing, session model architecture (at least my peculiar version of it), pretty much tosses out simple access to certain FileMaker fundamentals, like the flipbook, basic find controls, list view, etc. While I’m willing to live without these features (and the havoc they can wreak in the hands of uninitiated end users), there are times when I really miss them and the wonderful simplicity of what I now call “old school” FM development.

And so, since my exile, the question I keep returning to (along with a bag of maple leaf cookies) is, “am I really doing my clients a favor by designing this way, or would they be better off in the long run with a more standard design approach?” I guess I won’t really know until I’ve lived with it for a while and built up a larger time log that I can study. Until then, I suppose it’s a matter of celebrating the stuff that feels especially easy and living with the stuff that feels needlessly complicated, even if it involves clutching my chest from time to time and telling myself to “ride it straight to hell!”

As FileMaker developers, we take a lot of things for granted. For example, FileMaker’s Browse Mode/Find Mode feature is actually pretty slick; just place a field on a layout and it becomes both a data-update field as well as a query field without additional coding. However, when a layout is set to “save record changes automatically”, the frequency of people thinking they are in Find mode when they are actually happily clobbering data is enough to drive the most laissez-faire FileMaker developer nuts.

Sometimes, calling such problems “training-issues” just isn’t enough.

One solution is to roll your own Edit Mode feature. This technique uses the power of global variables in FileMaker 8+. In this example, I am going to combine scripts, a global variable and a custom privilege set to regulate users’ record-edit access.

Note: this article in intended to illustrate a general technique, do not rely solely on this example to secure your database.

The screenshots below are from a Mac but this tip is platform-agnostic.

Download the Example File

Note: the top level account is “admin” with no password

Step-by-Step

1. Create the table
In this example, I am going to start with a new file. I have defined a table called “contacts with a few basic fields.

Don’t worry about the “lock status” field for now; that is an interface bell-and-whistle that I added to give the user some visual feedback. Check out the example file to learn more about that later.

2. Create the “toggle” script
Next, I am going to create a basic script that toggles the edit mode. The script is going to use a global variable as a switch. It sets a global variable to either 1 or zero each time the script is called.

I have chosen to name my global variable switch $$__locked but you could call it whatever you wish. Just make sure it is a global variable because we want the variable to hold on to its value after the script is run.

The script works by checking first to see if $$__locked is “on” (i.e. has a value that isn’t zero or empty). If $$__locked is “on”, the script turns our switch “off” by setting $$__locked to zero.

3. Configure record level access

We need to tell FileMaker to check the global $$__locked before allowing our user to make record changes. Since record access is controlled by FileMaker privilege, I am going to go over to the Define>Accounts & Privileges… menu and create a User account with a custom privilege set called “User”…

To configure the record data access setting, I select ‘Custom Privileges’ from the ‘Records’ pull down menu of the ‘Edit Privilege Set’ screen…

I am going to control access to the “contacts” table by highlighting it and changing the ‘Edit’ privilege to ‘limited…”

My goal is to use a calculation expression to govern the user’s record modification activity. Records can be edited when:

not $$__locked...

FileMaker will evaluate the expression not $$__locked each time the user tries to modify a record. If $$__locked is zero or empty, the expression not $$__locked will evaluate to true (not locked) and the user will get to edit records. If $$__locked is “1″, our expression will evaluate to false and our user will be blocked from making any changes to ‘contact’ records.

4. Bells & Whistles

In the example file, you’ll note that I have added couple of simple re-login scripts to toggle between my “user” account and my “admin” account.

Finally, let’s cap it off by attaching a button to our script and by adding a “lock status” calculation field to create a simple indicator of the record lock status.

Cheers!

Solution
Create a loop-within-a-loop FileMaker script; use the power of indexed variables

Download Example File

Example
//create child records from lists of values example
//by Ernest Koe, The Proof Group LLC, April 18, 2007

Go to Layout [ “Parent” (Parent) ]
Go to Record/Request/Page [ First ]

//Loop through our parent records, store the parentid in a variable

Loop

//store the parentid in a variable while looping through each parent record
Set Variable [ $parentid; Value:Parent::parentid ]

//$n is just a counter to help us loop through child values
Set Variable [ $n; Value:1 ]

//$itemcount is the total number of child values
Set Variable [ $itemCount; Value:ValueCount ( Parent::childvalues ) ]

//While we are INSIDE the parent loop
//do a loop through the child values, storing each item the $childid variable

//the inner loop to store the child values

Loop

//the trick is to store each child id in a repetition of the variable!
Set Variable [ $childid[$n]; Value:GetValue ( Parent::childvalues ; $n ) ]

Set Variable [ $n; Value:$n + 1 ]
Exit Loop If [ $n > $itemCount ]
End Loop

Go to Layout [ “Child” (Child) ]

//inner loop that creates a new record for each value in childid[]

//$i is another counter
Set Variable [ $i; Value:1 ]

Loop
New Record/Request
Set Field [ Child::parentid; $parentid ]
Set Field [ Child::childid; $childid[$i] ]
Set Variable [ $i; Value:$i+1 ]
Exit Loop If [ $i ≥ $n ]
End Loop

Go to Layout [ “Parent” (Parent) ]
Go to Record/Request/Page [ Next; Exit after last ]
End Loop

Discussion
The crux of this technique to is realize that you can store and access data in variable repetitions; we can set childID[1] = “a”, childID[2] to “b”, childID[3] to “c” and so forth. The beauty of variables is that you can set their indexes (the repetition numbers of the variable) with the value of another variable, such as a counter that is incremented while in a loop.

Not far from 101, just off of Bell Road, is Taliesin West, home of
the architecture school started by Frank Lloyd Wright. Love or hate the
man, I’ve always appreciated the design approach he brought to
architecture. I think there is a lot to be learned from both his
successes and his failures, perhaps more from the latter. The same can be said of many architects. Earlier this
year Albert Harum-Alvarez invited a small group to tour the Julian Street Inn, a shelter serving the homeless population in
San Jose. The facility was designed by Christopher Alexander, whose
writing on design patterns have influenced not just architecture but
the software industry as well. The tour was incredibly useful in understanding architecture on the many different scales it exists.

Inertia led me into my current vocation of software development. My
avocation, on the other hand, is design, architecture, and
construction. It seems natural to me then that I would be drawn to the
ideas of Alexander and embrace the merger of art and information
science. As a self-professed software architect I look for patterns in
design at all levels of the system. Patterns exist not only in the user
interface but also in the structure of the application logic and data
model. I am constantly revising my practices in an effort to distill
them into the essential – everything else is just a distraction. To
that end, I’m not certain whether I agree or disagree with Joel Spolsky
(and by extension Don Norman) when he derides simplicity.
I think what he calls simplicity is what I would call a spare feature
set. My goal, on the other hand, is not the reduction of features but
rather making certain that each feature is implemented in as
unobfuscated a manner as possible. Sometimes this means moving things
into the data model, other times it means moving them out. Often it is
an attempt to bring a certain aesthetic to the application.

There’s a danger in confusing simplicity with simplistic or
unsophisticated. In data modeling "simple" is often used as a synonym for "flat and wide" when it comes to table structure. In application
design it is often used to berate scripting and UI control. I think we
lose sight of the real meaning of simplicity as it relates to our
applications. Simple is not a design methodology that describes how we
put things together, it’s a description of the user’s perception of the
end result. Sometimes simple methods are appropriate in creating simple
results. Other times it’s an engineering marvel under the hood to
present the user with a "simple" view of the world. The software architect’s job is to know when each approach is appropriate to the end goal of user simplicity.