In Basic, when a numerical value is declared as hexadecimal (ex: MyVar = &H00008000), the starting zeroes are ignored. Thus the resulting number is wrongly interpreted (value and type). This also applies to constants declares. This breaks code. I was mostly programming under v.5.4 without glitches. Since I upgraded to 7.0.5, the problem has arisen. This problem seems related to bug #62326 fix (applicable to 6.4). The code below shows the problem: Sub TestHex() Dim MyInt As Integer Dim MyLong As Long Dim MyVariant As Variant 'type 2 = integer ; 3 = long 'Rule: when the most significant bit is 1, should return a negative value (see bug #62326). 'see: https://bugs.documentfoundation.org/show_bug.cgi?id=62326 'should be: -32768, 2 MyInt = &H8000 MsgBox MyInt & Chr(10) & VarType(MyInt) 'OK. returns: -32768, 2 'should be: 32768, 3 MyLong = &H00008000 MsgBox MyLong & Chr(10) & VarType(MyLong) 'NOK. returns: -32768, 3 'should be: 32768, 3 MyVariant = &H00008000 MsgBox MyVariant & Chr(10) & VarType(MyVariant) 'NOK. returns: -32768, 2 End Sub I consider this to be a major or critical bug because it actually breaks code.
This is not a bug. The leading zeroes should not affect the type of the literal. But when you need to have a literal of specific type, use type characters: e.g., '&' for long (see tdf#130476). The previous behavior was a bug. Current behavior is not only correct, but also consistent with other Basic variants, like VBA. Compare: > MsgBox TypeName(&H00008000) > MsgBox TypeName(&H00008000&)
*** Bug 162367 has been marked as a duplicate of this bug. ***