I have a calculation that looks at a checkbox to see if it is checked. Depending on the state of the box the calculation returns either a yes or a no.

It works the first time. If I create a new record the calculation returns a value of Yes. If I check the checkbox the calc. returns a value of no. If I uncheck the checkbox the calc. is stuck on no, it wont switch back to yes.

Here is the calc. I am using. Any suggestions?

Case(Completed=1, "No"

Completed =0, "Yes", "No")

Do not evaluate if all ref. fields are empty is checked.

Do not store calculation results is checked.

LR

Hi:

Here is one simple option:

If(IsEmpty(Completed), "Yes" , "No" )

Ken

I have a calculation that looks at a checkbox to see if it is checked.

...

Here is the calc. I am using. Any suggestions?

Case(Completed=1, "No"

Completed =0, "Yes", "No")

You were sooooooo close

Case(Completed = "", "Yes","No")

Translation:

When the field "completed" is not equal to empty (i.e., it contains some databit) display "Yes", otherwise display "No".

Apart from the other solutions given, I would UNCHECK

Do not evaluate if all reference fields are empty

Seems to me an empty or zero value must also be evaluated in this case.

Harryk

Sorry, the equal sign should have the slash through it, making it mean "not-equal". I guess it's one of those characters which the UBB does not handle.

You could use an equal sign (instead the above with not-equal). It would look like: Case(Completed = "", "No","Yes")

Translation, When the field completed is empty disply "No" otherwise display "Yes"

You also have the choice of

Case(IsEmpty(completed), "Out", "In")

Ken, FWIW the Case is generally preferred over the If because of the way FM reads (processes) them.

Thanks for the info, Keith.

I have used If statements numerous times with no prob. I thought the only difference was that Case() is used for many conditions, where If() figures just one or the other.

I will keep your advice in mind for future things, though. Thanks

Ken

Sure thing Ken. If my understanding is correct the case statement operates on the first condition upon which it can act whereas the if conditional must be checked (gone through) in its entirety before it can act.

Yes, that's what I meant. Wow. You said that just like the manual reads.

Ken

Hello ibiubu,

It seems to me that what is at issue here is:

1. what values are on the valuelist defined for your 'Completed' field, and

2. what is the data type defined for that field.

All of the responses to date appear to have assumed that 'Completed' is a number field defined with a valuelist which returns the numeral '1' when checked.

If that were the case, then your original formula should have worked (albeit the tiniest bit less efficiently than some of the variations suggested by others here).

Given that you have indicated it is only returning a 'Yes' value when a new record is created (at which time the field is null), I suggest you take a look at the value list assigned to the field, the data type of the field, and the data in the field once it is checked and unchecked.

'Scholarly' debates about the relative merits of 'If' and 'Case' function syntax won't help at all if the 'Completed' field is not a number field locked to a value list that returns "0" or "1". On the other hand the approach you're using already will get you there if the values in your case arguments match those returned by the 'Completed' field in its checked and unchecked states.

"All of the responses to date appear to have assumed that 'Completed' is a number field..."

Ummmm. I hate to disappoint you, Cobalt Sky, but I was basing my responses on the valuelist being a text field and the Case calculation being Result is Text.

Actually, based on the title of the thread "Calc showing if a check box is checked?", I was assuming that one needed a field which was either blank (unchecked) or contained at least one databit (checked), which is sufficient. Populating a field at creation is an additional bit of processing which may not have been necessary. I figured that ibiubu would know what his deaign required.

ibiubu's original Case statement read:

Case(Completed=1, "No"

Completed =0, "Yes", "No")

I saw this as being not well-formed and unlikely to work

Since the not-equal sign did not show in my first response, I wrote a second response so that it used an equal sign:

Case(Completed = "", "No","Yes")

ibiubu should have been able to use that directly, or ibiubu could have revised his Case statement to be well-formed as:

Case(Completed=1, "Yes", "No")

*comment - compare this to ibiubu's Case statement.

This should have been sufficient since when Completed does not equal 1 it will return no and when it does equal 1 it will return yes. Additionally, when Completed is not 1 it can be anything. If the field is formatted as a number then that "anything but 1" can be from a blank field to a VLN, limited only by the number of characters which can be used in a FM field. But the blank field works just fine, which is why I used it.

It does not matter to the calculation field ("Result is text" since the result will be either Yes or No) is operating on a field (Completed) formatted as text or number. What matters is whether or not (as ibiubu originally offered) Completed = 1.

The responses were clues to how to form a Case statement. ibiubu should have been able to incorporate one of those three which I offered into his particular design or to change his design.

The discussion about the use of case vs if (thank you for thinking it was "scholarly") was directed more for the benefit of Ken, who I do believe did benefit by my comments, though I was hopeful that it would be of benefit to others as well.

I hope you find that this broadens your understanding of a checked checkbox and an unchecked checkbox. Incidentally, I performed (tested) each of my case statements prior to posting. And prior to this posting I also changed the checkbox I was using to from a text format to a number format and found, contrary to your contention, that the formatting of the checkbox as text or number did not matter to the outcome of the well-formed Case statement.

All of the responses to date appear to have assumed...

I assume nothing

Ken