Hi Mikhail, Thank you for you time in responding.
However, with all pleasant thoughts and collegial good will, I would ask you to kindly choose not to answer my question rather than to answer by questioning "why to bother" with what I am trying to do. First of all, there are MANY times where you want a boolean 1-0 number for many fields rather than one multi-value checkbox that you continually have to evaluate whether a particular values is checked therein. It is a "bad habit" that FileMaker lulls you into using the pseudo-array of the checkbox field. It is handy, don't get me wrong, but it is rarely the right choice for clean, robust data. I have many, many, many instances where I have had a long checkbox of items where I later had to break them out into individual boolean fields. Even in the simple example below, if I have one field called extras and I make it a checkbox with Rust Proofing, Extended Warranty, Radio Upgrade, and GPS System as checkbox options -- try writing your boss a report that summarizes number of "Extras Sales" by Type per month? -- all of a sudden you are writing complex calculations and summary fields. With the boolean field for each Extra you simply create summary field that totals the 1s (ones) and your report is written. Because you chose the traditional checkbox approach you are now writing individual calculations that become, in effect, boolean calculations for the existence of a value list item in a field. So you have lots of code to write and an extra field. Even when you do need to write calculations, boolean fields allow you all the power of multiplying by 1 or 0 -- if you have an ActiveStatusTF boolean and a ClassId serial id, you could create a "ClassId_active" calculation as ClassId * ActiveStatusTF -- or updated for FM9 you can have a multi-value relationship where ClassID = ClassID and Kone = ActiveStatusTF for a relationship to Active Classes. Then what do you do when the Marketing Departments wants everyone to use the phrase "Sound System Upgrade" instead of "Radio Upgrade"? Now you have a huge data management task on your hands. What do you do, do you add Sound System to your list? but then your reports won't run properly, you can append another Case line to your CountOfRadios calculation? or you can replace all instances where the database says "Radio Upgrade" and change the data to "Sound System Upgrade"? but then you have changed the data for a label -- it is better to let data be data and labels be labels; another core problem with using the FileMaker "out of the box" checkbox paradigm*. However, by creating boolean fields for each Extras option then the underlying field would remain radio_upgrade and you would merely change the Label from "Radio Upgrade" to "Sound System Upgrade" (and because FileMaker is so cool, you could also change the field name easily too, or not...) These same issues come up when making your solution multi-lingual, you need to adjust value lists and calculations and reports for each new language; however with booleans 1 is 1 in every language and 0 is 0 in every language. However, as it turns out, in the particular case that engendered this post I have no choice in the matter since the Enterprise Level Electronic Health Record tracked in Oracle already has these boolean numeric columns so I couldn't change my strategy if I wanted to. So if I need to I will revert back to one or more of my FM6 options for effecting a Boolean Checkox, but again, I would like to think that there is an elegant option in FM9 that I am not seeing... so answers to that question are still encouraged. Thanks in advance. Brad * Actually, for Radio Button fields you can separate Data from Labels now that you can capture value 1 and display only value 2 you can create a nice value list were the values are numeric and need not change and the labels can change independently -- but I wish FileMaker would make this possible in explicit value lists not just by using field values as HTML Forms do. On Tue, Aug 12, 2008 at 9:11 AM, Mikhail Edoshin <[EMAIL PROTECTED]> wrote: > If you really want to keep this setting (see below), try to set up an > auto-enter formula that evaluates to 1 if the value is 1 or to 0 if the > field is empty. I.e.: > > Auto-enter for rust_proofing = > If( rust_proofing = 1; > 1; > // else > 0 ) > > But if I were you, I'd just use a single text field "Options" with a value > list. Or many value lists to lay out the checkboxes nicely. (I normally set > such fields to use minimal index, because I think it's faster and these > fields don't need full word index anyway.) I really don't see why to bother > with many numeric 1/0 fields and try to make the checkbox widget to do stuff > it was not meant to do. I see it's more complex, but I don't see any return > on this complexity. > > Kind regards, > -- > Mikhail Edoshin > Information Analyst > Skeleton Key > > [EMAIL PROTECTED] > > > > On Aug 12, 2008, at 5:36 PM, Brad Lowry wrote: > > Hi All, >> >> Since FMI didn't see fit to hang on my every word and add "Boolean >> Checkboxes" as a feature... I gotta believe with all the new groovy stuff in >> FM9 that there is a better way than mine to approximate this feature. >> >> There are many, many applications that have a series of checkboxes that >> mean that it is a Boolean value: checked means True and unchecked means >> False. >> >> Let's say you are building a purchasing database for a Car Dealership, and >> in your Order.fp7 file you have these fields: >> rust_proofing >> extended_warranty >> radio_upgrade >> gps_system >> >> These are all things that buyers can choose to Add or Not Add. That is, >> you have these values as Number, and auto-enter 0 (false). >> >> On the layout that the Salesman uses you want a vertical list of four >> checkboxes, and they check the items that the buyer wants to add on to the >> purchase. >> The client insists that he doesn't want a column of Yes/No radio buttons. >> He wants checkboxes. >> >> If I use a traditional checkbox and a "1" value list and obscure all but >> the actual checkbox (hiding the "1") and I automate the value (number) as >> "0" and I check the checkbox I get a Type Error since it inserts a Line Feed >> and a "1" into the field after the "0" instead of changing it. >> >> In FM6 and prior I would make a "1" value list, make it the fields a >> non-enterable checkbox and attach a button to perform a Toggle Script for >> each value: >> Set(rust_proofing; 1 - Abs(Sign(rust_proofing))) >> # \_ Abs and Sign just in case the data gets "off track" the next click >> would get it back on track. >> >> But since the real requirement behind this example has more like 50 >> checkboxes, I was looking for something more elegant. >> >> Of course, I added a parameter to the button with the field name and >> captured it in $fieldname inside the script. However, since there is no way >> to choose the target field for Set command by calculation I couldn't do >> something Direct. >> >> So I realized I could Get(ActiveFieldContent) and put that into >> $fieldvalue then >> SetVariable($fieldvalue; 1 - Abs(Sign(GetAsNumber($fieldvalue)))) >> >> Then use Set without specifying a field and make the calculation >> $fieldvalue. >> >> Simple enough... EXCEPT! There is no way to GoToField by Calculation. So I >> labeled the field Object the same as the field name. and used Go to Object >> ($fieldname); but that wasn't the same as going to the field (somehow -- and >> I got lots of buggy results within debugger-dataviewer for >> Get(ActiveLayoutObjectName); but I was just messing around so maybe I was >> doing something wrong). >> >> So I thought that since the Object was selected that Go to Next Field() >> would start at the selected object, so I tried Go to Next Field and Go to >> Previous Field one after the other after going to the object and that didn't >> work either. >> >> I know that I can do something else I have done in FM6 and that is, commit >> record (exit record in 6), and then Go to Next Field(), set that to >> $firstfieldname, commit again and then loop through all the fields via Go to >> Next Field with Exit Loop If (Get(ActiveFieldName) = $fieldname or >> Get(ActiveFieldName) = $firstfieldname) [I won't go into the guts of it, but >> there are ways to distinguish from when the $firstfieldname is the target >> and when $firstfieldname indicates an error and prevents an infinite loop] >> >> But this is FileMaker 9! There has to be a more elegant way to do this!... >> I have to be missing something simple... >> >> NOTE: I *know* there are better ways to solve the Car Dealership example, >> this is not about solving that, it is an example of the abstract concept of >> having fields where you (well I) wish there was such a thing as a "boolean >> checkbox" layout "control style" where it appears like a checkbox, but >> behaves like a radio button for only 1 (checked) and 0 (unchecked) and since >> there is no such thing as a "boolean checkbox", how best to approximate that >> effect with buttons/scripts/objects and so on. This feature would be >> especially applicable to a list of items in a Portal. >> >> Thanks in advance for any hints. >> >> -- >> Sincerely, >> Brad >> > -- Sincerely, Brad
