Logical AND (Binary)

[datAdrenaline]

Hello dcb ...

>> Access sees Cint(True) as -1
But a Boolean remains a bool no matter what..
Thus
Cbyte(CBool(Cint(True))) = 255 <<

I am not sure of the point you are trying to make.

Coverting a boolean of True, which is supposedly returns a value of -1, *should* cause the CByte() function to overflow, just as the CByte(-1) did, but instead, the CByte() returned the fact that the right most 8 bits of the 16bit boolean value of True were set to 1, thus the return value of 255 since the Byte datatype is unsigned.

 

[Banana]

I suppose a better example is where the MS functions either return a null (together with a error raised sometimes) or ##### (please dont ask me which)
I am speaking out of context of my original post ....

Well, I'm a bit fuzzy but I think you may be talking about how API calls may have a return value?

If so, forget it. You see, there was a fundamental problem: They made the return value optional and thus programmers decided to ignore it so therefore, MS had to come up with a different way to alert the programmers of misuse of the API.

It's my personal opinion, but I'd much rather throw an error should a piece of my code be misused. Even if I'm the only developer using this piece of code, a slap on the head is much likely to produce a robust application.

 

[datAdrenaline]

Hello Banana ...

>> ... but rather "BitMask And SomeOption" <<

I hate to get nit-picky but the term "BitMask" is the filter you are masking a value with. In other words we mask the bits we are not interested in with a 0 in the respective bit position. So in the above, the bitmask is SomeOption. So ... it would be more appropriate to write something like ...

(BitFields And BitMask)

Definately not trying to be argumentative, or a "word police troll", but the way I described it is how I have seen (and used) the term "bitmask".

>> I wouldn't want a programmer to come to my code later on and think Option3 represented a different set of bit and mistakenly set up a situation where Option1 and Option2 should be exclusive but get set anyway because of Option3 <<

I understand, maybe not the best example --- should have checked for option3 first! --- but checking for 2 bits being set in a BitField value is pretty common (ie: Read, Write, Read/Write) or the constant dbSystemObject of the .Attributes property of a DAO.TableDef which equates to 10000000 00000000 00000000 00000010.

------

Like you say though, "Fair Enough" --- ultimately meaning that you understand what you are doing, how it works, and why you chose to do it that way, and the same applies to the method I utilize.

 

[dcb]

Hello dcb ...

>> Access sees Cint(True) as -1
But a Boolean remains a bool no matter what..
Thus
Cbyte(CBool(Cint(True))) = 255 <<

I am not sure of the point you are trying to make.

Coverting a boolean of True, which is supposedly returns a value of -1, *should* cause the CByte() function to overflow, just as the CByte(-1) did, but instead, the CByte() returned the fact that the right most 8 bits of the 16bit boolean value of True were set to 1, thus the return value of 255 since the Byte datatype is unsigned.

That the CByte was evaluating the -1 as an int - Cbyte(True) converts a 2 byte into single as you state - I would assume that this is because since the dawn of A/D convertors 255 is on and 0 is off and is still used in serial etc

 

[Banana]

If so, forget it. You see, there was a fundamental problem: They made the return value optional and thus programmers decided to ignore it so therefore, MS had to come up with a different way to alert the programmers of misuse of the API.

It's my personal opinion, but I'd much rather throw an error should a piece of my code be misused. Even if I'm the only developer using this piece of code, a slap on the head is much likely to produce a robust application.

I meant to include a link, but couldn't find the original link I was thinking about... nonetheless, I think this covers the rationale quite well.

HTH.

 

[Banana]

Definately not trying to be argumentative, or a "word police troll", but the way I described it is how I have seen (and used) the term "bitmask".

Thanks for pointing it out- thinking about it, it does make sense. I guess my memory futzed out on that one. As I said, I only used bitmasking once. I'm going to go out on a limb and speculate that bitmasking doesn't really readily lends itself in context of a data-centric application, though one could may use it within other applications.

I understand, maybe not the best example --- should have checked for option3 first! --- but checking for 2 bits being set in a BitField value is pretty common (ie: Read, Write, Read/Write) or the constant dbSystemObject of the .Attributes property of a DAO.TableDef which equates to 10000000 00000000 00000000 00000010.

Yeah, i can see how having a extra bit to set Read/Write could be useful since they're just a combination of two different attributes (e.g. Read & Write). Earlier, I was thinking of different options that may or may not correlate with other options, which was basically what I did... It would be something like this:

Public Enum ReportOptions
    MaterialsDetail = 1
    PartsDetail = 2
    ShowExpanded = 4
    Summarize = 8
End Enum

As you can see, they may be intended to be mutually exclusive (e.g. Summarize and ShowExpanded is incompatible becuase former does aggregating while latter gives more columns that only could be sensible should the report be non-aggregated, and Materials & Parts may be chosen alone, both or none, though it may be common to have say, MaterialsDetail + Summarize & PartsDetails + ShowExpanded as a two "quick selection" option for the user, hence my earlier suggestion of using a functions to separate the bit structure from um, implementation (I don't think that was right word but can't think of one right now).

Like you say though, "Fair Enough" --- ultimately meaning that you understand what you are doing, how it works, and why you chose to do it that way, and the same applies to the method I utilize.

110% agreed! Good to learn of other ways and reasoning behind it.

 

[dcb]

I meant to include a link, but couldn't find the original link I was thinking about... nonetheless, I think this covers the rationale quite well.

HTH.

I completely agree with you - I simply used the first example that came to my head....

EDIT: Really got lost here actually - was trying to say that as
?3 and 1 returns 1
and
?(3 and 1) = 1 returns boolean true
assuming that the variant would store 1 in the first example that this would make it a boolean.

After testing some more I have found that (3 and 1) even though returning the "bitmask" in the immediate window, converts into boolean when assigned directly to a variant.
Yourvariant = (3 and 1) stores True not 1
Interesting.....

 

[datAdrenaline]

>> After testing some more I have found that (3 and 1) even though returning the "bitmask" in the immediate window, converts into boolean when assigned directly to a variant.
Yourvariant = (3 and 1) stores True not 1 <<

.. Umm ... and how did you test that? ... Give this a shot:

Public Function testme()
    
    Dim x As Variant
    
    x = (3 And 1)
    
    Debug.Print VarType(x) & ":" & x
    
End Sub

You will note that in the immediate window after running the testme procedure you will see a "2:1". The 2 indicates the variant is holding an Integer, the 1 is the value that is being stored.

Are you storing the result in a Yes/No field of a table? ... if so, then you can try to write just about anything (1, -40000, 2000000, etc) to a Yes/No typed field and you will get a True/Yes stored in that field. The only values that get you a False in the Yes/No typed field is trying to write Null or 0. Due take note that a Yes/No typed field will NOT store a Null -- they are coerced to False, just as any other values are coerced to <ALL BITS ON>.

 

[Banana]

Hmm. Interesting.

a = (3 and 7) : debug.Print a
3
a = (3 and 8) : debug.Print a
0

However, if I do this:

?a=(3 and 8)
True
?a=(3 and 7)
False

I suspect what is going on is that if you use a variant and do this:

Var = (3 And 1) = 1

You get boolean 'True' or rather. However, if you do this:

Var = 3 And 1

then you get integer '1' instead of a boolean true.

I think it goes back to ChrisO's earlier point - not everything evaluates to True.

 

[dcb]

Ha datAdrenaline

I was using:
Dim strme As Variant
Debug.Print varType(strme = (7 And 1))
Print Out is 11 --- bool

Your right
Dim strme As Variant
strme = (7 And 1)
Debug.Print varType(strme)
Print Out 2 --- Int

As you will see at the start of the thread this all came about in looking for the easiest way to evaluate enumeration (and solved some 100 posts ago) thus i am going nowhere near a table

 

[datAdrenaline]

The reason that ...

?a=(3 and 8)
True

Occurrs is because (a) becomes a Variant, and Variants are initialized to Empty, and Empty is interpretted as 0 in a numeric context and a ZLS in a text context, so writting ...

? a=(3 and 8)

is the same as writting ...

? 0 = (3 and 8)

Which will return the value of True since 0 = 0.

Just like you can do this:

? a = ""
True

Again, a is a Variant that initializes to Empty, which when used in a text context is interpreted as a ZLS ("").

 

[datAdrenaline]

Hello dcb ...

>> I was using:
Dim strme As Variant
Debug.Print varType(strme = (7 And 1)) <<

My last post tells you why you get a result of 11 in the debug window with this test. strme is initialized to the special value of Empty. Empty is interpreted as a 0 in a numeric context and a ZLS in a text context. As such, you are escentially doing this with your code:

Debug.Print varType(0 = (7 And 1))

Which will return a boolean result.

 

[Banana]

A tangent:

I think this also illuminate why one should do well to avoid variants or similar data types where the type may be a bit too quick to implicitly convert the representation without programmer being actively aware of it. Indeed, it's no different from numerous bugs created by passing around a stray pointer that shouldn't have been passed in first place. Therefore, if we don't really need variants, best to avoid it although.

Of course, one could say but what if we don't know what data type in advance? Maybe we have a function that should be flexible enough to handle either DAO.Recordset or ADO.Recordset? In those cases, I say to use Object data type, which is slightly more specific than Variant and you still can use the 'Is' operator to check the object type at runtime. As for primitive data types, it may be preferable to coerce the incoming Variant into a certain data type then see if it's still valid for the function's purposes.

I can't think of a case where I needed a function that must return a Variant. Receive a Variant, sure, but not return it.

 

[gemma-the-husky]

I think we need to be very careful how we test things, for example: -

MsgBox (CBool(13 And 8))

Displays True in the English version of Access but might display Waar in the
So not everything that is true is equal to True, in fact most things are not.

note that this cbool line wasnt intended to do anything - i was just seeing how vba resolved certain expressions ie that a value of 8 was resolved to TRUE

 

[ChrisO]

Dave.

If you can’t quote me correctly then don’t quote me at all.

For reference, the quote as posted by Dave in post #34 is only part of what I said in post #14 in this thread.

 

[gemma-the-husky]

Dave.

If you can’t quote me correctly then don’t quote me at all.

For reference, the quote as posted by Dave in post #34 is only part of what I said in post #14 in this thread.

sorry chris, just saw this posting

i wasnt trying to take you out of context at all

i had just tried this bit of code to see how it would perform - it wasnt code
i would normally use - and i was just trying to clarify that particular point

i wasnt contradicting anything you had posted at all

no offence meant, and i hope none taken (well now, at any rate)

 

[ChrisO]

Dave.

It’s just that in my view a quote is a quote verbatim.
We should not pick and choose only those parts we think are important.

Regards,
Chris.