Overview

When using a field as a Boolean switch, it's desirable to limit the potential for bad data entry - or your own bad coding! This is similar to using a validation on a phone number field, where strict requirements must be met. Because the validation is strictly enforced, this will increase your level of confidence with regards to the contents of Boolean fields.

Guidelines

The following guidelines are suggested for Boolean fields.

  • Use a numeric field type
  • Prefix the field name with a Boolean word such as is or isNot (e.g. isStudent or isCustomer)
  • Specify the field to Always validate (image 1) and turn off "Allow user to override during data entry" (this assumes your users won't be directly interacting with the field and will likely be using a script or some type of trigger)
  • Specify a calculated validation similar to the following (image 2) 
    Self = 1 or Self = 0
  • Specify a custom message similar to the following 
    Internal developer message: This value should be Boolean!
    (this means if users actually see this message in production, you've done a bad job of coding) (wink) (image 3)

1/0 vs. 1/Null

This best practice assumes you're not attempting to HIGHLY OPTIMIZE your data storage and you're Ok with storing a zero (0) for a false value. If you're using a 1/Null setup, then you'll need to adjust the validation calculation accordingly

Image #1

Image #2

Image #3

Boolean switching via scripting

There are a number of ways to switch a 1 to a 0 and a 0 to a 1. The most efficient is to use the xor operator. Here's an example: 

$isStudent xor 1

or to use the standards specified on this site, the more readable is this 

$isStudent xor True
  • No labels

6 Comments

  1. Anonymous

    I also use the value of Boolean type in the same thinking.

    The validation is new to me but it's a good idea just for in case.

    "Boolean switching via scripting" is also new to me. I felt XOR is unfamiliar to most of FileMaker developers or not?

    I'm trying to make this type of calculation be short enough to understand.

    This is my case but I know it's still not readable well. Just to introduce.

    $isStudent ≠ TRUE

  2. Anonymous

    I'm not sure why you need to go to all the trouble. When I want to insist a field be boolean, I just add an auto-enter calc to the field:

    GetAsBoolean ( Self )

    and be done with it. No matter what gets put there turns into either a zero or a one.

    Will that work for your situation? How am I missing your point?

    Jonathan Fletcher

    1. Matt Petrowsky

      Thanks Jonathan, that's a good tip! However, there are times when you want to know your code is doing what it should be doing.

      In the event that you're setting a False value, when you mean to set a True value, the validation will catch this and let you know.

      If you don't care to know that your code is doing what you expect and you simply want to ensure the value is Boolean then you can certainly stop with just using an auto-enter calculation.

      Personally, the validation acts as a sort of unit test to make sure I'm coding things the way I want them to run.

      1. Jeremy Bante

        Has anyone run a test comparing the relative performance of validation vs. auto-enter?

  3. Anonymous

    Is there a reason for using something as unintuitive as $bool xor 1 rather than the very straightforward not $bool for toggling a boolean value. It's mentioned that xor is "the most effecient." This has been confirmed with testing? If readability is the primary goal, isn't not $boo the most readable?

    1. Jeremy Bante

      I use the "not $bool" in my own work. I just ran a performance test and found identical execution speed for both expressions (at 200,000 iterations).