Conditional Invisibility, part 1

I mentioned this technique in passing a few months ago (Portal Sorting, part 2), but today I would like to examine it in greater detail. Have you ever had a text object or a field that you wanted to selectively change based on some logical condition? For example, say you have a check box, and want the label next to the check box to change depending on whether the box is checked or not, like so:

In the old (pre-FileMaker 9) days, you could have used auto-enter or calculated field trickery, but now, thanks to the modern miracle of Conditional Formatting, you can make this happen at the layout level, rather than having to pollute your table schema.

Of course there are other ways to accomplish this, including using script triggers and/or merge variables, but today I want to concentrate on Conditional Formatting, and feel free to follow along in today’s demo file, conditional-label.zip, if you are so inclined.

So let’s pretend for a moment we’re absolute beginners when it comes to Conditional Formatting. The concept is straight-forward: attach a Boolean calculation to a layout object, and if the result is true, change the formatting of that object.

Also, in case it isn’t obvious (if we’re beginners, why would it be?), the check box in the above example is attached to a value list consisting of the number 1, but sized so narrowly that the 1 is hidden.

To the right of the carefully sized check box we can place both the text labels, one overlapping the other (the order is not important).

And at this point, we might  expect that we could set all labels to some hypothetical “invisible” property, and then use Conditional Formatting to selectively make a given label visible.

But as per the dialog above, we would seek in vain for “invisible” and “visible” options — they simply do not exist. But surely there is some way? Of course there is, but before we let the rabbit out of the hat, let’s consider another approach.

Can we achieve invisibility by changing the text color to the background color (in this case, white) based on some sort of reverse Boolean logic? Well… yes and no…

Yes, we can selectively turn a text label white, but no, the result is not satisfactory.

I was bemoaning the lack of a proper visibility control to Stephen Dolenski a few years ago, and he told me the secret: you can achieve invisibility by  setting the text size to 500 points.

The drawback, for me at any rate, is that positive logic is easier for my brain to deal with than negative logic. In other words, I’d rather define the problem in terms of showing the correct label, rather than hiding the incorrect one.

However, this is a drawback I am willing to live with. The following tells the “empty” label to vanish if the box is checked, and the “checked” label to vanish if the box is unchecked.

And voila, you can check and uncheck the box with no ghostly artifacts.

What’s really going on here? Why does this trick work? Well, it turns out that 500 pt text is too large to display within the tiny confines of the label object, effectively rendering it invisible. If the box is unchecked, and you resize the text label for “checked” to, say, 550 px wide by 300 px tall, the illusion will be exposed…

…but assuming you don’t allow that to happen, your secret will be perfectly safe, and your users will be none the wiser.

So, in a nutshell: When you want the text label to disappear, conditionally format its text size to be 500 points. The size of the label’s bounding box will not change, and the effect will be that the text completely vanishes. Can the text be larger? No, 500 pt is the maximum FileMaker allows. Can the text be smaller? Sure, within reason, but I like to play it safe and stick with 500.

In part 2, we’ll look at some other applications of this technique.