Explain: Using Or between longs during Assignment

[TheSmileyCoder]

I am working on a project, in which I want to make a backup of the backend before a baseline if performed. Last time I needed a backup from the IT department it took them more then a week to restore a file, and then they restored it without giving me the permission to read it, which took another week. Therefore I need to make a backup myself before baseline.

I first tried using FileCopy, but run into trouble because the file is being marked in use. I then found this by Dev Ashish:
http://access.mvps.org/access/api/api0026.htm
that I could use.

I've implemented it and it works fine. However I am having trouble understanding the logic behind one of the code lines, namely line 5 of the below:

Private Const FOF_RENAMEONCOLLISION As Long = &H8
Private Const FOF_FILESONLY As Long = &H80
Private Const FOF_SIMPLEPROGRESS As Long = &H100
 
lngFlags = FOF_SIMPLEPROGRESS Or _
           FOF_FILESONLY Or _
           FOF_RENAMEONCOLLISION

I simply dont understand how using OR between differnt longs can give any kind of sensible output (Though I am sure it makes sense somehow).

So could anyone please explain what line 5 does?

[sierra7]

Hi Smiley
It adds the values together!

It's a new one on me but if you put a break point and debug it (or in my case insert message boxes) you can show this.

S7

[TheSmileyCoder]

No thats not exactly the case. At least I dont believe so. Typing in the immediate pane:

? 7 or 9=15
? 255 or 110=255
? 78 or 87=95

So its not addition as far as I can see.

[sierra7]

This is nuts isn't it?

In your first example the values where all HEX and the values of &H8, &H80 and &H100 evaluated to 8,128,256 and lngFlags to 392 which is the total.

I shall play some more!
S7

[sierra7]

I have played some more!

I confirm that by using arbitary numbers you seem to get odd results but Help say that when using numerical expressions 'Or' does a bit-wise comparison.

So it's converting everything into binary. As we have three values we will have three virtual rows. If any column position has a '1' then that column's result is '1' and only if all column values are '0' will the result be zero. Hence 8 (1000) 0r 128 (10000000) 0r 256 (110000000) equates to (110001000) or 392.

Using your example with "7 or 9" gives 7 (111) 0r 9 (1001) = 15 (1111)
The two 'ones' from the RH colum are interpreted as True + True = True (i.e. 1 + 1 = 1)
You learn something every day! Although I dont know when I will make use of this!

I suppose the RGB() function is doing something similar when adding elements of Red, Green & Blue to generate a colour number.

Thanks for the entertainment!
S7

[NeoPa]

S7:
I suppose the RGB() function is doing something similar when adding elements of Red, Green & Blue to generate a colour number.

Absolutely.

In fact it's a bitwise OR. You've pretty well explained it already. It treats each bit separately and the result of each bit resolves to 1 or 0 depending on the two bits found in the original values at the same bit position. AND, NOT and XOR work in similar ways. This type of processing is very useful for managing multiple flags in a single value. For a good example of this see the Buttons parameter of the MsgBox() function.

Notice that each usable value is a power of two so that it directly represents a number which is a single 1 bit with all the rest 0s. In such simple scenarios adding is perfectly possible and works. In anything more complex though that would not work reliably when the OR is what is actually required (So use OR rather than + when dealing with such things for preference).

Another thing you may find somewhat surprising is that these bitwise operations are exactly those used with the same operators when using If or IIf(). Hence the value True is actually -1 (all bits = 1) rather than 1 (only bit 0 = 1). Also, any non-zero value is treated as True (or, at least, not False). Try it sometime :

If 7 And 24 Then Debug.Print "True"
If 9 And 24 Then Debug.Print "True"

None of the 1 bits of the first one overlap, so nothing is printed for that one, but in the second one bit 3 (=8) is common to both therefore "True" is printed to the Immediate Pane.

[NeoPa]

S7:
The two 'ones' from the RH colum are interpreted as True + True = True (i.e. 1 + 1 = 1)

Absolutely again. This is Boolean Arithmetic invented by George Boole. A fundamental of logic explanation and processing.

[TheSmileyCoder]

First, thanks to both of you for taking the time to explain so well.

NeoPa
Another thing you may find somewhat surprising is that these bitwise operations are exactly those used with the same operators when using If or IIf(). Hence the value True is actually -1 (all bits = 1) rather than 1 (only bit 0 = 1). Also, any non-zero value is treated as True (or, at least, not False).

I do not understand the part about true being all bits=1.... Any chance of more explanation on that?


Ok, so especially your example using this with AND starts to make some sense to me, in terms of practical application.
I did this small code as test to myself, all the shown vb constants are part of the constants used for the msgbox function:

Dim lngCombined  As Long
    lngCombined = vbOKCancel Or vbCritical Or vbMsgBoxHelpButton
 
 
    If vbOKCancel And lngCombined Then Debug.Print "vbOKCancel"
    If vbCritical And lngCombined Then Debug.Print "vbCritical"
    If vbMsgBoxHelpButton And lngCombined Then Debug.Print "vbMsgBoxHelpButton"

When you use a msgbox you might combine some of the parameters to specify both what buttons to display as well as whether a Question mark/Exclamation mark should appear. With your example, I now see how the msgbox function (probably) decodes the values given, something I have wondered about for some time.

[NeoPa]

Smiley:
With your example, I now see how the msgbox function (probably) decodes the values given, something I have wondered about for some time.

Absolutely yet again :-)

Smiley:
I do not understand the part about true being all bits=1.... Any chance of more explanation on that?

A pleasure.

For simplicity, we'll start by reducing our integer value to 4 bits - just to make the numbers smaller and easier to follow. We're dealing with signed values, so a 4-bit variable can handle from 0 (0h in Hex) to 15 (Fh) in unsigned or from -8 (8h) to 7 (7h) as signed. Let's just take a closer look at the signed interpretations of all the possible values, as this is how we typically refer to them :

Signed  Hex  Binary  Boolean
-8       8h   1000    True    
-7       9h   1001    True
-6       Ah   1010    True
-5       Bh   1011    True
-4       Ch   1100    True
-3       Dh   1101    True
-2       Eh   1110    True
-1       Fh   1111    True
 0       0h   0000    False
 1       1h   0001    True
 2       2h   0010    True
 3       3h   0011    True
 4       4h   0100    True
 5       5h   0101    True
 6       6h   0110    True
 7       7h   0111    True

While each value that isn't exactly zero triggers the True path in an If statement or IIf() function, only the value -1 is equal to the predefined value True (Hence these two entries only are highlighted).

If you haven't dealt with storage of negative numbers before then the reason they are stored as they are, to represent the numbers as they are (Instead of a single bit used as a pos/neg flag followed by the Absolute value of the number in the remaining bits for instance), is that binary arithmetic in computer processors work in such a way as to flow from negative to positive this way without any special handling. Consider these same binary values but treat them as unsigned. Let's now look at incrementing (A simple addition of one) -6, which is 10 (Ah) when viewed as unsigned. You would expect 10 to increment to 11 (Bh) yes? What do we notice as the signed verion of 11? -5. Let's now look at some values that overflow. To do this it may help to consider an extra bit (Binary-digIT) to the left of the four we have. This is usually handled as an Overflow flag in the processor, but it is sensible for us to understand it as an extra bit. We just ignore this bit once it's comleted the process.

 0 - 1 ==> 1 0000 - 0 0001 ==> 16 - 1 ==> 10h - 1h =  Fh ==> 15 ==> 0 1111 (or 1111) ==> -1
-1 + 1 ==> 0 1111 + 0 0001 ==> 15 + 1 ==>  Fh + 1h = 10h ==> 16 ==> 1 0000 (or 0000) ==>  0

Does that all make sense? And does it answer your question adequately?