Thanks for the replies. But still I can't understand.
If I run the following code, I receive a "Test passed" message box although the variable is integer and not double.
Code:
Sub test()
Dim test As Integer
test = 1
Select Case test
Case 0.8, 1#, 1.2, 1.6, 2#
MsgBox "Test Passed"
Case Else
End Select
End Sub
i believe so.
But.. see the other numbers. they all have decimals. the
author of the code is only being explicit on the datatype.
you can write 0.8# for 0.8 , but since It Already has decimal,
suffixing it with "#" is rather redundant.
only 1 and 2 are suffxied with # (to clearly emphasized that
all in the list are double values).
See if this helps...
The limits for Long datatype numbers are -2147483648 to 2147483647.
Paste this into a standard module and run it
Code:
Sub NumberTest()
Dim L As Long
L = 2147483646
Debug.Print L + 1
End Sub
You will as expected see 2147483647 in the immediate window.
Now set L=2147483647 & run again. You will get an overflow error and the result is outside the limits
So far, nothing unexpected
Finally enter L =2147483648 and press Enter. Note what happens. Does it make sense to you?
NOTE Using Debug.Print CDbl(L) + 1 will work in all three cases
I can't say that the question or the code makes any sense to be but I can explain why you might want to use the # when writing code with hard-coded variables.
Computer languages (all of them, not just VBA) examine all the arguments in an expression and convert them to a common data type. So, what the # that follows the integer values is doing is preventing the VBA interpreter from converting the data type or choosing anything other than a double(single, I'm not sure what the # designates).
I'm not going to take the time to try to create an example that will cause an error but I have 50+ years of writing code and I have a lot of scars. Several of them caused by the mistake of loosing control of my intermediate results data types. Whenever you are doing calculations, keep the intermediate results in mind and do your best to prevent type conversions from happening mid-calculation.