>Oh, but it is. If you use it as a value, it's a .t. or .f., but you may check with IsBlank() to see if it's blank or really .f.

Hiya Dragan!
I had left this thread go because I thought it was pointless. But since you jumped in and I'm sitting here praying for Markus to sign on... I'm going to comment.

Yeah sure you can milk a blank value and even a null value out of a logical field. But to me, this makes as much sense as putting a street address number on your car. Sure you can live in your car... but it's meant to be a transport vehicle and not a place of residence.

A logical field is intended to be .t. or .f. in my opinion. 2 values, nothing more. Now thanks to a quirk in the VFP IDE we can milk a blank out of it, and even a null. But doing so really means your using that logical for something over and above what it should be used for... in other words I think this practice used in an application is bad design. Now I could agree with checking a logical field for state of blankness if your dealing with a client server type of scenario where a record could be added and data entry not completed. In that case, testing for a blank logical can reflect an incomplete action and trigger the app's proper error handling. But then again it's my practice to always populate a logical with .F. and not be lazy and leave it blank.

So when you get right down to it, yeah sure you can get more than a .t. or .f. from a logical field but why? Reminds me of getting scolded as a kid where Mom would say "Answer me young lady, YES OR NO". And after one or two iterations of that statement in a single session, it wasnt real hard to learn that "YES OR NO" meant one of two things. Neither of which including giving Mom a BLANK stare nor acting NULL =D)

Just my .02 US$ worth.