>>I'd always thought that checkboxes can have 3 values: 1 for checked, 0 for unchecked and (something else) for "Naaaaah, not sure - some of the list are and some aren't"). But I also knew, of course, that they can be T/F (never sure of the circumstances though when they're one or the other)
>>
>>So in testing the value in code I first tested for 1 or 0. VFP gave me an operator/operand type m-m error, so I went along with it, quite happily, and tested for T/F - all well and good.
>>
>>Since, I've made some changes to the form, but none to the checkbox logic. Now I go to test the form, click a checkbox and get an operator/operand type. In debug, the value of the checkbox is 0! So it's changed its mind!
>>
>>Give me a break!
>>
>>Has anyone found this problem and/or is there a definitive solution? I didn't set the initial value to the checkbox. Of course, in edit I find that it's 1. I've set it to .T. and don't get this error now. I presume it was .T. first of all - hence the first operator/operand type m-m error.
>>
>>I've had a similar problem with listboxes not being able to decide whether their value is char or num in the past, but I can't cite a definite example now. I've had to change code that was working, testing, say for num, to that testing for char. Very frustrating.
>
>Terry,
>If they're not bound to data then by default use numeric 0/1 (unless you set the value property to T/F). When bound to data then datatype decides if it's numeric or logical.
>Numeric 2 is for undetermined state (ie: null).
>Cetin

Thanks Cetin

Like I said, I've done this to force the checkboxes into T/F. What I wanted to know is: if they already were that by default (hence the 1st error I got), and I accommodated this in my code, then how come they managed to find themselves as 1/2 values later on.

This problem is not beyond me, it just irks me that they can change their minds about what data trype they are.