How do i make a Unsigned 32 Bit Integer?

I think it would be System.UInt32.

Visual Basic .NET does not support the use of unsigned data types.  You can keep track of an instance of System.UInt32, but you cannot assign it an unsigned value (that is, a value greater than  System.In32.MaxValue).

UInteger in .NET 2.0.

[code]

        Public Overridable Overloads Sub InsertByte(ByVal b As Byte)
            Stream.WriteByte(b)
        End Sub

        Public Overloads Sub InsertByte(ByVal b As SByte)
            Stream.WriteByte(b)
        End Sub

[/code]

I am trying to Overload my InsertByte function depending on the value given.. it is not working -_-

[quote author=BaDDBLooD link=topic=10451.msg98509#msg98509 date=1107721489]
[code]

        Public Overridable Overloads Sub InsertByte(ByVal b As Byte)
            Stream.WriteByte(b)
        End Sub

        Public Overloads Sub InsertByte(ByVal b As SByte)
            Stream.WriteByte(b)
        End Sub

[/code]

I am trying to Overload my InsertByte function depending on the value given.. it is not working -_-
[/quote]

Okay, [edit]: Unsigned integral values 16 bits and larger are not supported in Visual Basic .NET.  Signed 8-bit values are not supported in Visual Baisc.  Therefore, the following types (which are not CLS-compliant) are not supported in Visual Basic .NET: SByte, UInt16, UInt32, UInt64.

Why do they exist? Are they "CLS Compliant" in framework 2.0?

[quote author=BaDDBLooD link=topic=10451.msg98668#msg98668 date=1107810859]
Why do they exist? Are they "CLS Compliant" in framework 2.0?
[/quote]

Yes.  UInteger, UShort, ULong.

[quote author=dxoigmn link=topic=10451.msg98674#msg98674 date=1107813218]
[quote author=BaDDBLooD link=topic=10451.msg98668#msg98668 date=1107810859]
Why do they exist? Are they "CLS Compliant" in framework 2.0?
[/quote]

Yes.  UInteger, UShort, ULong.
[/quote]

I still don't think they're CLS-compliant; other things such as Generics, which will be available in 2.0 as well, are not CLS-compliant.

CLS-Compliant means that a particular language implements the very basic common components of the common language specification, which is the specification that allows the different languages to interoperate with one another.  A C# library that uses System.UInt32 inside of functions will work inside a Visual Basic .NET application.  However, if functions expose (such as a return value or accepted parameter) a non-CLS-compliant type, Visual Basic .NET will have trouble with it.

[quote author=MyndFyre link=topic=10451.msg98688#msg98688 date=1107817023]
I still don't think they're CLS-compliant; other things such as Generics, which will be available in 2.0 as well, are not CLS-compliant.

CLS-Compliant means that a particular language implements the very basic common components of the common language specification, which is the specification that allows the different languages to interoperate with one another.  A C# library that uses System.UInt32 inside of functions will work inside a Visual Basic .NET application.  However, if functions expose (such as a return value or accepted parameter) a non-CLS-compliant type, Visual Basic .NET will have trouble with it.
[/quote]

Generics are CLS-compliant.  So are those types I explained above in 2.0

[quote author=dxoigmn link=topic=10451.msg98693#msg98693 date=1107818268]
[quote author=MyndFyre link=topic=10451.msg98688#msg98688 date=1107817023]
I still don't think they're CLS-compliant; other things such as Generics, which will be available in 2.0 as well, are not CLS-compliant.

CLS-Compliant means that a particular language implements the very basic common components of the common language specification, which is the specification that allows the different languages to interoperate with one another.  A C# library that uses System.UInt32 inside of functions will work inside a Visual Basic .NET application.  However, if functions expose (such as a return value or accepted parameter) a non-CLS-compliant type, Visual Basic .NET will have trouble with it.
[/quote]

Generics are CLS-compliant.  So are those types I explained above in 2.0
[/quote]

Generics are not CLS-compliant.  See the namespace browser at [url]http://www.dotnet2themax.com/dotNetBrowser/ShowType.aspx?asm=mscorlib&ns=System.Collections.Generic&type=Comparer{T}[/url].  Note that the System.CLSComplianAttribute attribute is applied to the type, with the property IsCompliant as false.  For information on System.UInt32, see [url]http://www.dotnet2themax.com/dotNetBrowser/ShowType.aspx?asm=mscorlib&ns=System&type=UInt32[/url].

They are an extension to the Common Language Specification.  They *can* be supported by multiple languages in a common way -- and they are in 2.0 -- but they are not required to be.

so if i switch to 2.0, my problem would lessen?

If you are using generics  :P

[quote author=BaDDBLooD link=topic=10451.msg98704#msg98704 date=1107821493]
so if i switch to 2.0, my problem would lessen?
[/quote]

You don't need to have those functions at all.  You're converting things such as my packet buffer class, correct?  Those functions wouldn't be available to you in VB.NET anyway; you can just skip over them.

[quote author=MyndFyre link=topic=10451.msg98723#msg98723 date=1107823719]
[quote author=BaDDBLooD link=topic=10451.msg98704#msg98704 date=1107821493]
so if i switch to 2.0, my problem would lessen?
[/quote]

You don't need to have those functions at all.  You're converting things such as my packet buffer class, correct?  Those functions wouldn't be available to you in VB.NET anyway; you can just skip over them.
[/quote]

Buffer.CS, which i converted to vb, which i then combined with my old PacketBuffer.vb to make my new PacketBuffer.vb.

I Just thought having those options would be beneficial... but if i can't get it to work than oh well.

I Would have just used your Buffer.CS class by.. iteself, but i wanted to experience with making inherited classes.  I might add a C# project with some of your open source classes.  I don't know as of yet.  Having both C# and VB7 projects might be a good learning experience.  Unfortunately, all your classes are sort of... vague and tied together;  Which makes it EXTREMELY difficult to use one, or the other.

In Whidbey (which Visual Studio 2005 is) generics are CLS-compliant along with many other things.

http://blogs.msdn.com/bclteam/archive/2004/12/21/328585.aspx
http://geekswithblogs.net/khanna/archive/2005/01/07/19376.aspx
http://hyperthink.net/blog/PermaLink,guid,e4a5b50b-ccbc-48b6-82aa-78a8afa79677.aspx

mmm, then that's change from the most recent "official" release.  My libraries still show it flagged for non-CLS-compliant.

Does this really matter?

[quote author=shout link=topic=10451.msg98807#msg98807 date=1107882295]
Does this really matter?
[/quote]

Yes; if the types are CLS-compliant, that means that any language that supports .NET *must* support these features.

Ah.

SByte to Byte, Byte to SByte enjoy
[code]    Public Function ByteToSByte(ByVal bytAr As Byte) As SByte
        Dim sbytOut As SByte

        sbytOut = SByte.Parse((bytAr - 128).ToString)

        Return sbytOut
    End Function

    Public Function SByteToByte(ByVal bytAr As SByte()) As Byte()
        Dim i As Integer
        Dim sbytOut(bytAr.Length - 1) As Byte

        For i = 0 To (bytAr.Length - 1)
            sbytOut(i) = Val(bytAr(i).ToString) + 128
        Next

        Return sbytOut
    End Function

    Public Function SByteToByte(ByVal bytAr As SByte) As Byte
        Dim sbytOut As Byte

        sbytOut = Val(bytAr.ToString) + 128

        Return sbytOut
    End Function

    Public Function ByteToSByte(ByVal bytAr As Byte()) As SByte()
        Dim i As Integer
        Dim sbytOut(bytAr.Length - 1) As SByte

        For i = 0 To (bytAr.Length - 1)
            sbytOut(i) = SByte.Parse((bytAr(i) - 128).ToString)
        Next

        Return sbytOut
    End Function[/code]No idea why you want this however this is one way of doing the conversion.