By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,084 Members | 1,969 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,084 IT Pros & Developers. It's quick & easy.

Data Type Conversion bug??

P: n/a
With VS2003 I get the following problem:

This works in C#...
{
ulong u=0xF070061073000000; <-no problem initializing variable to
this value
Console.WriteLine(u);
}
But this fails in VB.NET...
Dim u As UInt64 = Convert.ToUInt64(&HF070061073000000) <-Overflow error
here!
Console.WriteLine(u)
Why am I able to initialize the variable in C#, yet intializing to the same
value in VB.NET dies? A ulong and a UInt64 are both the same underlying
framework datatype, a System.UInt64, so what's the problem?

Am I missing something here? Is there a workaround?

Randall

Jul 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Randall,
VB.NET does not understand unsigned numbers!

Using ildasm.exe: VB.NET is attempting to call Convert.ToUInt64(Int64).

Seeing as you are attempting to put a massively negative number (long) into
a unsigned value, it is throwing the exception.

C# works because C# understands unsigned numbers. CSharp is calling
Convert.ToUInt64(UInt64).

Remember in VB.NET (&HF070061073000000) is a Long value, there is no ULong
in VB.NET (yet).

As it stands now you will need to wait for the next version of VB.NET
("Whidbey" (2004)) to get support for unsigned values.
http://msdn.microsoft.com/vstudio/pr...o/roadmap.aspx

Hope this helps
Jay

"Randall Banning" <randall.b spam @ not rogers.com> wrote in message
news:_e*********************@news01.bloor.is.net.c able.rogers.com...
With VS2003 I get the following problem:

This works in C#...
{
ulong u=0xF070061073000000; <-no problem initializing variable to
this value
Console.WriteLine(u);
}
But this fails in VB.NET...
Dim u As UInt64 = Convert.ToUInt64(&HF070061073000000) <-Overflow error
here!
Console.WriteLine(u)
Why am I able to initialize the variable in C#, yet intializing to the same value in VB.NET dies? A ulong and a UInt64 are both the same underlying
framework datatype, a System.UInt64, so what's the problem?

Am I missing something here? Is there a workaround?

Randall

Jul 19 '05 #2

P: n/a
Thanks Jay for the answer. I'm not saying I like it <g>, but it's an answer.

Ok, what I'll do is build what I want into a separate C# DLL then reference
that in my VB project. It's not an ideal solution but it'll hold me until
2004.

Randall

"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message
news:eu**************@TK2MSFTNGP10.phx.gbl...
Randall,
VB.NET does not understand unsigned numbers!

Using ildasm.exe: VB.NET is attempting to call Convert.ToUInt64(Int64).

Seeing as you are attempting to put a massively negative number (long) into a unsigned value, it is throwing the exception.

C# works because C# understands unsigned numbers. CSharp is calling
Convert.ToUInt64(UInt64).

Remember in VB.NET (&HF070061073000000) is a Long value, there is no ULong
in VB.NET (yet).

As it stands now you will need to wait for the next version of VB.NET
("Whidbey" (2004)) to get support for unsigned values.
http://msdn.microsoft.com/vstudio/pr...o/roadmap.aspx

Hope this helps
Jay

"Randall Banning" <randall.b spam @ not rogers.com> wrote in message
news:_e*********************@news01.bloor.is.net.c able.rogers.com...
With VS2003 I get the following problem:

This works in C#...
{
ulong u=0xF070061073000000; <-no problem initializing variable to
this value
Console.WriteLine(u);
}
But this fails in VB.NET...
Dim u As UInt64 = Convert.ToUInt64(&HF070061073000000) <-Overflow error here!
Console.WriteLine(u)
Why am I able to initialize the variable in C#, yet intializing to the

same
value in VB.NET dies? A ulong and a UInt64 are both the same underlying
framework datatype, a System.UInt64, so what's the problem?

Am I missing something here? Is there a workaround?

Randall


Jul 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.