What's the best way to handle Booleans?

[kennedy]

Boolean fields are fairly common and can be handled a number of ways; each way will have certain advantages and disadvantages. What do you experienced guys consider the best way?

The basic discussion of Booleans is as a Number; 0 for false and non-zero for true. But if a Number is always stored as a double-precision float, that's not really the most efficient mechanism. Worse, its kinda clunky when it comes to presentation...

A checkbox is always a cool way to present Booleans. But with FileMaker, it seems that approach makes it difficult, if not impossible, to search on. And Booleans are commonly useful in Finds. So, I rejected that.

My next favorite presentation is Y/N (beating out Yes/No because it lays into a tight column so much easier). Its obvious, clear, and easy to see. While it is certainly possible to display a Number as Y/N, it is rather clunky. Far more clunky than I want to endure on common Booleans.

Thus, I've been using Text for Booleans where I limit it to the values Y and N from my Boolean value list. This presents very easy. With a popup on the field, its almost as simple as a checkbox to use... but supports Find perfectly. Calculations are a bit clunkier, but not bad... and I prefer to keep clunkiness there.

Sooo, how do you all, who have much more FMP experience than I, prefer to represent Boolean fields??

[harryk]

The way I often use booleans is as a 0 or 1 value. I often attach a button to the field doing a toggle. In the script I use:

setfield(value;abs(value-1)

which makes it toggle between 0 and 1.

For the representation I often use the option in the Field format for numeric displays: Show zero as ***, show non-zeros as ***.

There you can attach No and Yes, or 'nothing' and

[LiveOak]

Had the replay almost complete when Netscape took a dump...sigh! I'll see if I can duplicate the response.

I wouldn't worry too much about the internal representation of numbers. I prefer to use numbers for booleans. In a number field, "1" and "0" or "T" and "F" or "Y" and "N" or "Yes" and "No" or "True" and "False" all evaluate the same. Checkbox representations are not appropriate because they allow both values to be entered. Radio button are problematic, as a "1" will not display on the radio button as "Yes" if the value list is set to "Yes"/"No", even if the field is set to display boolean numbers as "Yes" and "No". Blanks will evaluate correctly as "No" in calculations, but again may not display properly. A "0" entered into a number field set to display as a boolean with the values, say, "T" and "F" will correctly display as "F", but a blank will not.

Having said all that, text will work just fine.

-bd

[Keith M. Davie]

"What's the best way to handle Booleans?"

Since each soluiton is different, there is no "best way". Whenever I can I use a blank and a databit. In browser solutions I have found this to be very efficient, esp. when dealing with fmp-if conditionals on format files.

Also, again depending on the solution, calc-fields and scripts often benefit through using IsEmpty, e.g.

And the blank can be used to tell if some event has occurred (field is blank until filled as part of an event), or to cause the display of a message if fields are left blank which must have data.

Text, Numeric, Container - it doesn't matter.

[keshalyi]

Regarding liveoak's comment that you can't use radio buttons with a 1/0 boolean, since they won't display Y or N...

Actually, I do this all the time. Its more convenient for me to store a 1 or a 0, its more convenient for the viewer to see a Y or an N. So I just make a radio button field, make the text the color of the background, and type my own text over where the 1 and 0 were. Unless I just misunderstood whta you were saying?

[kennedy]

In a number field, "1" and "0" or "T" and "F" or "Y" and "N" or "Yes" and "No" or "True" and "False" all evaluate the same.

Yeah, that appealed to me... and its real good for importing. But in practice, if I choose to always display "Y" and "N", then that's what the user will type (or maybe "y" or "n"). But if "1" and "0" occasionally leakes through, average people will typically be stumped. Even if "True" or "False" shows up, they'll be confused for a moment. With a Text field, consistency will be preserved.

Checkbox representations are not appropriate because they allow both values to be entered.

Oh, sorry... I didn't mean FMP's built in checkbox mechanism... agreed that's all wrong. Rather, I meant using a single checkbox where checked means Yes and not checked means No. There's only two states possible; no way to select both. (To implement that, you need a calculated container field = If(boolean_field, check_on, check_off) and a script on the field to toggle the value.

In playing with that and with the Popup field I've been using, I've come to realize that the advanced-data-entry person would rather hit [Tab] Y [Tab] rather than have to grab the mouse to hit the darn box.

So, while I have a bunch of cute checkboxes and popup menus in my aqua template, I'll probably only use those on forms that are just that... lots of checkboxes... like an attendance sheet: you scan the barcode on the sheet and up pops a list of students and you simply run down the list hitting the checkboxes.

But where I have a mix if text, number, and boolean fields, I think my users will prefer if I just make them text (validated for "Y" or "N").

Opinions?

[CobaltSky]

But with FileMaker, it seems that approach makes it difficult, if not impossible, to search on. And Booleans are commonly useful in Finds. So, I rejected that.

I'm not sure why you are having trouble using checkboxes in find mode. It has always worked fine for me and my users.

Checkbox representations are not appropriate because they allow both values to be entered.

If the checkbox field is attached to a value list with only a single value (1), then there is then no way to select 'both values'. Moreover the syntax of any dependent calculations or actions can deal as readily with a null :1 "value pair" as they can with the more conventional 0:1 pair.

[kennedy]

If the checkbox field is attached to a value list with only a single value (1), then there is then no way to select 'both values'. Moreover the syntax of any dependent calculations or actions can deal as readily with a null :1 "value pair" as they can with the more conventional 0:1 pair.

Clever! However, find doesn't work! Well, you can find "Y"... but you can't find "N" because its the same as null which is taken as "no criteria".

I'm not sure why you are having trouble using checkboxes in find mode. It has always worked fine for me and my users.

Ooops. Same "sorry" as before. I am using an OSX-look-alike template... so my Boolean field was displayed with a container field... and the container field vanishes in Find mode. It actually still works... if you click on it, it toggles the field... but you have to know where to click. But I suppose that works okay as long as I give both... the text field and the "sexy" container field showing the checkbox... in find mode, no checkbox... but that's workable.

I've been experimenting with the various tab behaviors. Popup lists allow you to tab into them and popup the list... but if you press 'y' or 'n' and then 'tab', it leaves the choice as it was. So, the power-user will be tabbing along and typing values in, but will have to remember to use 'enter' instead of 'tab' after y/n fields. Ick!!

Sooo.... given all that... and given my desire to have OSX LAF...

I think I will display all Booleans wih a normal field to the left of a container field containing a checkbox. Power users can 'tab' 'y' 'tab'; casual users can hit the checkbox; the checkbox looks good and is intuitive; the checkbox vanishes in Find, but the 'y' or 'n' is still there.

That UI choice will work fine with both Text and Number fields. Using Number is advantageous since it makes scripting easier. However, I feared having 0's and 1's leak through. But after more experimentation, I believe FMP actually saves numbers as text... thus, as long as my users can only input 'y' or 'n', they will only see 'y' or 'n'.

So, Number it is.

As for the associated value list, I was going to do Y and N. But that also accepts 'y' and 'n'. And since people will tend to be lazy if they can and not hit the SHIFT key, I am far more likely to get consistency if I go with 'y' and 'n' in my value list.

If anyone disagrees with those conclusions, or sees issues I missed, please let me know.

Thanks.

P.S. Now that I look at the conclusion, I wonder if this thread isn't better placed in Right Brain... or even Value Lists. Ahh, well. Thanks again.

[CobaltSky]

Clever! However, find doesn't work! Well, you can find "Y"... but you can't find "N" because its the same as null which is taken as "no criteria".

But find does work.

If you are finding 'Yes' values, it works in the normal way.

If you are performing simple finds to locate 'No' values, you check the box and enable the 'omit' option (in the status bar).

If there is a desire to be able to perform complex finds, then it will be desirable to attach the following script to the checkbox:

If ["YourCheckbox"]

If ["Status(CurrentMode)"]

Set Field ["YourCheckbox", "="]

Else

Set Field ["YourCheckbox", ""]

EndIf

Else

Set Field ["YourCheckbox", "1"]

EndIf

---

If the checkboxes are graphical (ie container based), then you will want to make the calculating containers (which work in Browse Mode) transparent, and stack both a static graphic (of an unchecked checkbox) and a global container field (also transparent) underneath them. Your script should then look like:

If ["Status(CurrentMode)"]

If ["YourCheckbox = "=""]

Set Field ["YourCheckbox", ""]

Set Field ["gFindCheckbox", ""]

Else

If ["YourCheckbox = "1""]

Set Field ["YourCheckbox", "="]

Set Field ["gFindCheckbox", "Checkbox_X_graphic"]

Else

Set Field ["YourCheckbox", "1"]

Set Field ["gFindCheckbox", "Checkbox_Tick_graphic"]

EndIf

EndIf

Else

If ["YourCheckbox"]

Set Field ["YourCheckbox", ""]

Else

Set Field ["YourCheckbox", "1"]

EndIf

EndIf

---

This way you will have a bimodal checkbox in browse mode (with graphics) AND a tri-modal checkbox in find mode off/searchY/searchN (also with graphics).

A script which takes the user into Find mode and/or a script which performs the find (preferably both), should include the step Set Field ["gFindCheckbox", ""] so that the next find starts fresh with 'null' checkbox graphics showing. A script for 'Modify Last Find' will also require a few extra steps to set the tri-modal checkbox graphics to the correct state to match the reinstated 'find' criteria.

[kennedy]

If there is a desire to be able to perform complex finds, then it will be desirable to attach the following script to the checkbox:

But the resulting interaction doesn't seem reasonable. To search for Y, you click the checkbox. To search for N, what do you do? You click on Y and then click on it again to turn it off? Visually, it will look like you made no change. I don't think users will follow that well at all. Worse, you won't be able to turn it off the criteria once you turn it on, other than by leaving Find mode and returning. And finally, Modify Last Find will be unworkable (since you won't be able to see the difference between "=" and "").

Am I missing something?

If the checkboxes are graphical (ie container based), then you will want to make the calculating containers (which work in Browse Mode) transparent, and stack both a static graphic (of an unchecked checkbox) and a global container field (also transparent) underneath them.

Just to be clear, assuming you have multiple Boolean fields, you'd need to have one global gYourCheckboxFind for each boolean field YourCheckbox. And then recovering that state for ModifyLastFind would require an explicit section for each of those field-pairs. Hmmm... I think my users can live without the cute checkbox in Find mode.

Thanks for pointing that out... hadn't thought of Modify Last Find... now, I feel good about FMP's choice to blank container fields in Find mode!

Please let me know if I am missing something on the single-value method above... it does have a certain elegance.

Brian

[CobaltSky]

You're correct that the non-graphical method I suggested does not provide adequate visual feedback for all cases - and that it is not fully tri-modal in the form I provided (without full visual feedback, full tri-modal functioning is not a lot of use). Which is why I went on to decribe a full tri-modal implementation with full visual feedback.

It's true that if you have a lot of checkboxes, there is some work involved in setting it up this way. As to whether it's worth it for your project, that's your call... However in quite a few situations with high end applications, I find that there is an expectation that a separate interface will be provided for searching (with all search criteria entered either into global fields or into a related 'search log' file - or both). Compared to this, trimodal graphics and scripts on the same layouts that are used for browsing is a snap. So I guess it depends on where you're coming from as to whether you regard the tri-modal solution as 'a lot of work'