1

I am ready to file this one under 'w' for tWilight zone weird!

I have a user control class, and have this in the definitions

Private Const m_def_FillColor As Long = &H99FF

THEN:

Private Sub UserControl_InitProperties()
    m_FillColor = m_def_FillColor

Now if I investigate in the immediate window:

? m_def_FillColor
-26113

I figure. Ok. That might be why I am getting an error when I attempt to use this as color. I check the hexadecimal value and get:

? hex( m_def_FillColor )
FFFF99FF

Bizarre, right?

So I do a check on the value &h99ff in the immediate window:

? &h99ff
-26113

Hmm.. weird, right?

I try forcing the cast and being explicit with the conversion:

? clng( &h000099ff )
-26113

And just for 'shits and grins' I do a conversion between the two:

? hex( clng( &h000099ff ) )
FFFF99FF

and just for fun, i check out a nonconverted cast:

? hex( &h000099ff )
99FF

Buyt JUST in case. I figure, I am going to see what's goin on with the actual decimal value:

? hex( clng( 39423 ) )
99FF

In any case. I'm shuttin down for the evening, I figure I have a memory issue and just need to reboot, I have tried restarting the project so that's not the issue.

In any case, has anyone ever seen this kind of issue?

I am hoping a reboot and a good night's sleep 'cures' it..

But... am i doing something obvious and/or ignorant and flat out missing something?

My goal is to plug the value &h000099ff into a long value. I'm pretty good with Visual Basic programming, this is something I've done billions of times, so I just wanna make sure I am not missing something obvious here!

Goodnight and thank you in advance for helping with this.. weirdness...

I blame a memory issue. But still not sure.

Nadeem_MK
  • 7,533
  • 7
  • 50
  • 61
Q The First Timelord
  • 69
  • 7
  • possible duplicate of [Setting colors in Hex and Decimal behaving differently](http://stackoverflow.com/questions/12644456/setting-colors-in-hex-and-decimal-behaving-differently) – Alex K. Jan 27 '15 at 11:22

3 Answers3

4

Add a & at the end of the number

'1 form with:
'  1 command button : name=Command1
Option Explicit

Private Const A As Long = &H99FF
Private Const B As Long = &H99FF&

Private Sub Command1_Click()
  Print "A : " & CStr(A)
  Print "B : " & CStr(B)
End Sub
Hrqls
  • 2,944
  • 4
  • 34
  • 54
  • I actually figured this out later that night, You are spot on! VB can be so fickle at times! Gotta love these undocumented assignment features. – Q The First Timelord Jan 28 '15 at 17:31
  • It's quite logical: in vb6 numbers are treated as integers. Declaring the const as long converts the integer value of the hex number (which is the negative) .... By explicitly putting the number as long, it is treated as a long from the start, and therefore not negative when it is converted (again) to long as the const ... – Hrqls Jan 28 '15 at 17:40
0

Your problem results from lack of understanding of 2's complement integer format used to store integers on modern computers.
Read Two's_complement especially section on Sign Extension.

VB only has signed integer variables so specifying &H99FF is interpreted as a 16 bit signed 2's complement integer and because the most significant bit is set it represents a negative number, decimal -26113. To convert it to a Long (32 bit) and to get the same signed integer value it must be sign extended to &HFFFF99FF which is the 32 bit 2's complement representation for -26113

Adding the trailing & to the constant tells VB that &H99FF& is a Long (32 bit) value already and thus does not need any sign extend conversion when assigned to a Long variable.

JonN
  • 2,498
  • 5
  • 33
  • 49
-1

Most programming languages only have the concept of signed integers.

Just assign it &h000099ff and it will work. But if you read it it will be treated as signed.

The function you are calling only cares about the bits not how VB6 interprets them.

Why assign a constant to a variable in the first place. Constants and string literals (they end up the same thing) are fast.

Also it seems a funny value for a colour.

Serenity
  • 73
  • 3
  • Check out the answer I commented on above. If you read my example in full, you'd see that placing your value in the hex function reduces it down to &h99ff, which for some reason was converting improperly into a long. As for longs vs strings are most definitely not the same thing. A string is a pointer to an allocated portion of memory which contains that value, whereas a long directly contains the value. MUCH faster operating with constant numerics than strings. Why that color? I'm designing LCARS custom controls. Why a constant? I don't want the initial color changed. – Q The First Timelord Jan 28 '15 at 17:39
  • All you did was add an obsolete type character, that one should not be using, to a literal. Type characters are not part of VB even though they work. It took me years to learn not to write strings$ like this. If you don't read it the bits remain the same. It's a signed v's unsigned thing. – Serenity Jan 28 '15 at 17:58
  • Actually it's not. And while I'm not new to VB, this is the first time I've used it in a while. The problem is quite simply casting, If I do not add the & at the end, at least in my universe, then it automatically casts to an integer regardless of the type.. Add the '&' and you get a long. And - again - at least in my universe - the string vs string$ translates to the same thing. Pull up an assembly level debugger, you should see - at least in my universe - the same assembly generated for the assignment. String operations are SUBSTANTIALLY slower, particularly in tight loops. – Q The First Timelord Jan 29 '15 at 18:53