|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Option Strict OnWith the option strict On set.....
Dim fs As FileStream = File.OpenRead(strFile) With fs Dim buffer(fs.Length) As Byte ' <--- Option Strict On disallows implicit conversions from 'Long' to 'Integer'. ' other stuff.. End With been a while i did VB code... can somebody help me what I am doing wrong here... Vijay Op Fri, 31 Mar 2006 15:12:05 -0600 schreef Vijay:
Show quoteHide quote > With the option strict On set..... Vijay,> > Dim fs As FileStream = File.OpenRead(strFile) > > With fs > Dim buffer(fs.Length) As Byte ' <--- Option Strict On disallows implicit > conversions from 'Long' to 'Integer'. > ' other stuff.. > End With > > been a while i did VB code... can somebody help me what I am doing wrong > here... > > Vijay The report is about the array bound. fs.length is a long (64 bits signed integer) and the dim statement expects an integer. VB would have to implicitely convert the long to an integer (32 bits signed integer). Unles you have really big files, the type conversion will be safe here. Make it explicit by using ctype(fs.length,integer) instead of fs.length. Another note in case you don't realise: value fs.length is the upper bound of the array. The array starts at index 0, so you are declaring an array of fs.length + 1 long. Renze. Thanks Renze.. I just posted here to make sure I was not typing something
wrong... its been a while I did VB coding... Vijay Show quoteHide quote "Renze de Waal" <re***@dewaal.speedlinq.nl> wrote in message news:uj99dkphze7c.rj6wieg7oeaa$.dlg@40tude.net... > Op Fri, 31 Mar 2006 15:12:05 -0600 schreef Vijay: > >> With the option strict On set..... >> >> Dim fs As FileStream = File.OpenRead(strFile) >> >> With fs >> Dim buffer(fs.Length) As Byte ' <--- Option Strict On disallows implicit >> conversions from 'Long' to 'Integer'. >> ' other stuff.. >> End With >> >> been a while i did VB code... can somebody help me what I am doing wrong >> here... >> >> Vijay > > > Vijay, > > The report is about the array bound. fs.length is a long (64 bits signed > integer) and the dim statement expects an integer. VB would have to > implicitely convert the long to an integer (32 bits signed integer). > > Unles you have really big files, the type conversion will be safe here. > Make it explicit by using ctype(fs.length,integer) instead of fs.length. > > Another note in case you don't realise: value fs.length is the upper bound > of the array. The array starts at index 0, so you are declaring an array > of > fs.length + 1 long. > > Renze. But the point.. I am reading files as a stream from my app display window to
create zip files the users can export... I am hoping nobody hits the Integer mark... VJ Show quoteHide quote "Renze de Waal" <re***@dewaal.speedlinq.nl> wrote in message news:uj99dkphze7c.rj6wieg7oeaa$.dlg@40tude.net... > Op Fri, 31 Mar 2006 15:12:05 -0600 schreef Vijay: > >> With the option strict On set..... >> >> Dim fs As FileStream = File.OpenRead(strFile) >> >> With fs >> Dim buffer(fs.Length) As Byte ' <--- Option Strict On disallows implicit >> conversions from 'Long' to 'Integer'. >> ' other stuff.. >> End With >> >> been a while i did VB code... can somebody help me what I am doing wrong >> here... >> >> Vijay > > > Vijay, > > The report is about the array bound. fs.length is a long (64 bits signed > integer) and the dim statement expects an integer. VB would have to > implicitely convert the long to an integer (32 bits signed integer). > > Unles you have really big files, the type conversion will be safe here. > Make it explicit by using ctype(fs.length,integer) instead of fs.length. > > Another note in case you don't realise: value fs.length is the upper bound > of the array. The array starts at index 0, so you are declaring an array > of > fs.length + 1 long. > > Renze. p Fri, 31 Mar 2006 16:30:26 -0600 schreef Vijay:
> But the point.. I am reading files as a stream from my app display window to Vijay,> create zip files the users can export... I am hoping nobody hits the Integer > mark... > > VJ > If your files can be that long, try to avoid having to keep the file in memory. I am not quite sure what you are doing, but maybe you can process the files in parts. Renze. Ok here is some MSDN documentation I found... that helps... gives peace of
mind... You can convert the Integer data type to Long, Single, Double, or Decimal without encountering a System.OverflowException error. I guess if the above is true... VB should not complain... the C# complier does not .. why is VB complaining... Vijay Show quoteHide quote "Renze de Waal" <re***@dewaal.speedlinq.nl> wrote in message news:uj99dkphze7c.rj6wieg7oeaa$.dlg@40tude.net... > Op Fri, 31 Mar 2006 15:12:05 -0600 schreef Vijay: > >> With the option strict On set..... >> >> Dim fs As FileStream = File.OpenRead(strFile) >> >> With fs >> Dim buffer(fs.Length) As Byte ' <--- Option Strict On disallows implicit >> conversions from 'Long' to 'Integer'. >> ' other stuff.. >> End With >> >> been a while i did VB code... can somebody help me what I am doing wrong >> here... >> >> Vijay > > > Vijay, > > The report is about the array bound. fs.length is a long (64 bits signed > integer) and the dim statement expects an integer. VB would have to > implicitely convert the long to an integer (32 bits signed integer). > > Unles you have really big files, the type conversion will be safe here. > Make it explicit by using ctype(fs.length,integer) instead of fs.length. > > Another note in case you don't realise: value fs.length is the upper bound > of the array. The array starts at index 0, so you are declaring an array > of > fs.length + 1 long. > > Renze. The length of an array is defined as a 32-bit integer. The Length
property in the FileStream class is a Long. Convert it to an Int, but you should really check to see if the length of the file yo are trying to read isn't too large to fit in a 32-bit int. The confusion for me here is C-Sharp does not seem to complain. VB being
simple enough why is there this problem? Maybe they have not changed the underlying type from VB?? VJ <za***@construction-imaging.com> wrote in message Show quoteHide quote news:1143841803.101695.88850@z34g2000cwc.googlegroups.com... > The length of an array is defined as a 32-bit integer. The Length > property in the FileStream class is a Long. Convert it to an Int, but > you should really check to see if the length of the file yo are trying > to read isn't too large to fit in a 32-bit int. > Vijay wrote:
> The confusion for me here is C-Sharp does not seem to complain. VB being It would appear this is one the very few times when VB.NET is stricter> simple enough why is there this problem? Maybe they have not changed the > underlying type from VB?? than C#. To wit, and to recap for C#ers just joining us: C# int[] f = new int[3000000000]; // compiles, throws System.OverflowException at run time VB.NET Dim f(3000000000) As Integer ' Will not compile: error is 'Constant expression not representable in type Integer' So here, the VB.NET compiler can work out at compile time that 3 billion is bigger than an Int32, and thus can't be used as an array size (a CLS limitation I would suspect); but the C# compiler can't, or doesn't care. Your particular example can be examined also: C# long l = 3000000000; int[] f = new int[l]; // compiles, throws System.OverflowException at run time VB.NET Dim l As Long = 3000000000 Dim f(l) As Integer ' Will not compile under Option Strict On: ' error is 'Option Strict On disallows implicit conversions from '<type1>' to '<type2>'' ' WILL compile with Option Strict Off: throws System.OverflowException at run time So for me the question is, why does C# allow this unstated cast from long to int to compile? To that end I have xposted to the C# group -- Larry Lard Replies to group please Vijay wrote:
> The confusion for me here is C-Sharp does not seem to complain. VB being It would appear this is one the very few times when VB.NET is stricter> simple enough why is there this problem? Maybe they have not changed the > underlying type from VB?? than C#. To wit, and to recap for C#ers just joining us: C# int[] f = new int[3000000000]; // compiles, throws System.OverflowException at run time VB.NET Dim f(3000000000) As Integer ' Will not compile: error is 'Constant expression not representable in type Integer' So here, the VB.NET compiler can work out at compile time that 3 billion is bigger than an Int32, and thus can't be used as an array size (a CLS limitation I would suspect); but the C# compiler can't, or doesn't care. Your particular example can be examined also: C# long l = 3000000000; int[] f = new int[l]; // compiles, throws System.OverflowException at run time VB.NET Dim l As Long = 3000000000 Dim f(l) As Integer ' Will not compile under Option Strict On: ' error is 'Option Strict On disallows implicit conversions from '<type1>' to '<type2>'' ' WILL compile with Option Strict Off: throws System.OverflowException at run time So for me the question is, why does C# allow this unstated cast from long to int to compile? To that end I have xposted to the C# group -- Larry Lard Replies to group please Vijay wrote:
> The confusion for me here is C-Sharp does not seem to complain. VB being It would appear this is one the very few times when VB.NET is stricter> simple enough why is there this problem? Maybe they have not changed the > underlying type from VB?? than C#. To wit, and to recap for C#ers just joining us: C# int[] f = new int[3000000000]; // compiles, throws System.OverflowException at run time VB.NET Dim f(3000000000) As Integer ' Will not compile: error is 'Constant expression not representable in type Integer' So here, the VB.NET compiler can work out at compile time that 3 billion is bigger than an Int32, and thus can't be used as an array size (a CLS limitation I would suspect); but the C# compiler can't, or doesn't care. Your particular example can be examined also: C# long l = 3000000000; int[] f = new int[l]; // compiles, throws System.OverflowException at run time VB.NET Dim l As Long = 3000000000 Dim f(l) As Integer ' Will not compile under Option Strict On: ' error is 'Option Strict On disallows implicit conversions from '<type1>' to '<type2>'' ' WILL compile with Option Strict Off: throws System.OverflowException at run time So for me the question is, why does C# allow this unstated cast from long to int to compile? To that end I have xposted to the C# group -- Larry Lard Replies to group please Yea seems like at some point VB.NET is smarter or strict here... I took all
the trouble to move from VB to C# over last 2 years.. now you have given me some reason to come back.. :-) Actually speaking I should be a loyalist here for VB, because my initials are VB...:-) Vijay Show quoteHide quote "Larry Lard" <larryl***@hotmail.com> wrote in message news:1144163023.023565.93240@i40g2000cwc.googlegroups.com... > > Vijay wrote: >> The confusion for me here is C-Sharp does not seem to complain. VB being >> simple enough why is there this problem? Maybe they have not changed the >> underlying type from VB?? > > It would appear this is one the very few times when VB.NET is stricter > than C#. To wit, and to recap for C#ers just joining us: > > C# > int[] f = new int[3000000000]; > // compiles, throws System.OverflowException at run time > > VB.NET > Dim f(3000000000) As Integer > ' Will not compile: error is 'Constant expression not representable in > type Integer' > > So here, the VB.NET compiler can work out at compile time that 3 > billion is bigger than an Int32, and thus can't be used as an array > size (a CLS limitation I would suspect); but the C# compiler can't, or > doesn't care. > > Your particular example can be examined also: > > C# > long l = 3000000000; > int[] f = new int[l]; > // compiles, throws System.OverflowException at run time > > VB.NET > Dim l As Long = 3000000000 > Dim f(l) As Integer > ' Will not compile under Option Strict On: > ' error is 'Option Strict On disallows implicit conversions from > '<type1>' to '<type2>'' > ' WILL compile with Option Strict Off: throws System.OverflowException > at run time > > So for me the question is, why does C# allow this unstated cast from > long to int to compile? To that end I have xposted to the C# group > > -- > Larry Lard > Replies to group please > Yea seems like at some point VB.NET is smarter or strict here... I took all
the trouble to move from VB to C# over last 2 years.. now you have given me some reason to come back.. :-) Actually speaking I should be a loyalist here for VB, because my initials are VB...:-) Vijay Show quoteHide quote "Larry Lard" <larryl***@hotmail.com> wrote in message news:1144163023.023565.93240@i40g2000cwc.googlegroups.com... > > Vijay wrote: >> The confusion for me here is C-Sharp does not seem to complain. VB being >> simple enough why is there this problem? Maybe they have not changed the >> underlying type from VB?? > > It would appear this is one the very few times when VB.NET is stricter > than C#. To wit, and to recap for C#ers just joining us: > > C# > int[] f = new int[3000000000]; > // compiles, throws System.OverflowException at run time > > VB.NET > Dim f(3000000000) As Integer > ' Will not compile: error is 'Constant expression not representable in > type Integer' > > So here, the VB.NET compiler can work out at compile time that 3 > billion is bigger than an Int32, and thus can't be used as an array > size (a CLS limitation I would suspect); but the C# compiler can't, or > doesn't care. > > Your particular example can be examined also: > > C# > long l = 3000000000; > int[] f = new int[l]; > // compiles, throws System.OverflowException at run time > > VB.NET > Dim l As Long = 3000000000 > Dim f(l) As Integer > ' Will not compile under Option Strict On: > ' error is 'Option Strict On disallows implicit conversions from > '<type1>' to '<type2>'' > ' WILL compile with Option Strict Off: throws System.OverflowException > at run time > > So for me the question is, why does C# allow this unstated cast from > long to int to compile? To that end I have xposted to the C# group > > -- > Larry Lard > Replies to group please > Sorry wrong post... I was another group..
VJ Show quoteHide quote "VJ" <vijayba***@yahoo.com> wrote in message news:u5g7ao$VGHA.4416@TK2MSFTNGP15.phx.gbl... > Yea seems like at some point VB.NET is smarter or strict here... I took > all the trouble to move from VB to C# over last 2 years.. now you have > given me some reason to come back.. :-) Actually speaking I should be a > loyalist here for VB, because my initials are VB...:-) > > Vijay > > "Larry Lard" <larryl***@hotmail.com> wrote in message > news:1144163023.023565.93240@i40g2000cwc.googlegroups.com... >> >> Vijay wrote: >>> The confusion for me here is C-Sharp does not seem to complain. VB being >>> simple enough why is there this problem? Maybe they have not changed the >>> underlying type from VB?? >> >> It would appear this is one the very few times when VB.NET is stricter >> than C#. To wit, and to recap for C#ers just joining us: >> >> C# >> int[] f = new int[3000000000]; >> // compiles, throws System.OverflowException at run time >> >> VB.NET >> Dim f(3000000000) As Integer >> ' Will not compile: error is 'Constant expression not representable in >> type Integer' >> >> So here, the VB.NET compiler can work out at compile time that 3 >> billion is bigger than an Int32, and thus can't be used as an array >> size (a CLS limitation I would suspect); but the C# compiler can't, or >> doesn't care. >> >> Your particular example can be examined also: >> >> C# >> long l = 3000000000; >> int[] f = new int[l]; >> // compiles, throws System.OverflowException at run time >> >> VB.NET >> Dim l As Long = 3000000000 >> Dim f(l) As Integer >> ' Will not compile under Option Strict On: >> ' error is 'Option Strict On disallows implicit conversions from >> '<type1>' to '<type2>'' >> ' WILL compile with Option Strict Off: throws System.OverflowException >> at run time >> >> So for me the question is, why does C# allow this unstated cast from >> long to int to compile? To that end I have xposted to the C# group >> >> -- >> Larry Lard >> Replies to group please >> > > Sorry wrong post... I was another group..
VJ Show quoteHide quote "VJ" <vijayba***@yahoo.com> wrote in message news:u5g7ao$VGHA.4416@TK2MSFTNGP15.phx.gbl... > Yea seems like at some point VB.NET is smarter or strict here... I took > all the trouble to move from VB to C# over last 2 years.. now you have > given me some reason to come back.. :-) Actually speaking I should be a > loyalist here for VB, because my initials are VB...:-) > > Vijay > > "Larry Lard" <larryl***@hotmail.com> wrote in message > news:1144163023.023565.93240@i40g2000cwc.googlegroups.com... >> >> Vijay wrote: >>> The confusion for me here is C-Sharp does not seem to complain. VB being >>> simple enough why is there this problem? Maybe they have not changed the >>> underlying type from VB?? >> >> It would appear this is one the very few times when VB.NET is stricter >> than C#. To wit, and to recap for C#ers just joining us: >> >> C# >> int[] f = new int[3000000000]; >> // compiles, throws System.OverflowException at run time >> >> VB.NET >> Dim f(3000000000) As Integer >> ' Will not compile: error is 'Constant expression not representable in >> type Integer' >> >> So here, the VB.NET compiler can work out at compile time that 3 >> billion is bigger than an Int32, and thus can't be used as an array >> size (a CLS limitation I would suspect); but the C# compiler can't, or >> doesn't care. >> >> Your particular example can be examined also: >> >> C# >> long l = 3000000000; >> int[] f = new int[l]; >> // compiles, throws System.OverflowException at run time >> >> VB.NET >> Dim l As Long = 3000000000 >> Dim f(l) As Integer >> ' Will not compile under Option Strict On: >> ' error is 'Option Strict On disallows implicit conversions from >> '<type1>' to '<type2>'' >> ' WILL compile with Option Strict Off: throws System.OverflowException >> at run time >> >> So for me the question is, why does C# allow this unstated cast from >> long to int to compile? To that end I have xposted to the C# group >> >> -- >> Larry Lard >> Replies to group please >> > >
Show quote
Hide quote
"Larry Lard" <larryl***@hotmail.com> wrote in message There's no cast involved; the C# spec says, regarding the sizes used in news:1144163023.023565.93240@i40g2000cwc.googlegroups.com... > > Vijay wrote: >> The confusion for me here is C-Sharp does not seem to complain. VB being >> simple enough why is there this problem? Maybe they have not changed the >> underlying type from VB?? > > It would appear this is one the very few times when VB.NET is stricter > than C#. To wit, and to recap for C#ers just joining us: > > C# > int[] f = new int[3000000000]; > // compiles, throws System.OverflowException at run time > > VB.NET > Dim f(3000000000) As Integer > ' Will not compile: error is 'Constant expression not representable in > type Integer' > > So here, the VB.NET compiler can work out at compile time that 3 > billion is bigger than an Int32, and thus can't be used as an array > size (a CLS limitation I would suspect); but the C# compiler can't, or > doesn't care. > > Your particular example can be examined also: > > C# > long l = 3000000000; > int[] f = new int[l]; > // compiles, throws System.OverflowException at run time > > VB.NET > Dim l As Long = 3000000000 > Dim f(l) As Integer > ' Will not compile under Option Strict On: > ' error is 'Option Strict On disallows implicit conversions from > '<type1>' to '<type2>'' > ' WILL compile with Option Strict Off: throws System.OverflowException > at run time > > So for me the question is, why does C# allow this unstated cast from > long to int to compile? To that end I have xposted to the C# group creating a new array: (section 7.5.10.2 Array creation expressions) Each expression in the expression list must be of type int, uint, long, or ulong, or of a type that can be implicitly converted to one or more of these types It also says it's a compile-time error if a constant expression evaluates to a negative, but is silent about what happens if it evaluates to a number that's too large. In fact, nothing I can see in the spec refers to the largest possible size of an array being limited to what fits in an int. Apparently the language has no such restriction.
Show quote
Hide quote
"Larry Lard" <larryl***@hotmail.com> wrote in message There's no cast involved; the C# spec says, regarding the sizes used in news:1144163023.023565.93240@i40g2000cwc.googlegroups.com... > > Vijay wrote: >> The confusion for me here is C-Sharp does not seem to complain. VB being >> simple enough why is there this problem? Maybe they have not changed the >> underlying type from VB?? > > It would appear this is one the very few times when VB.NET is stricter > than C#. To wit, and to recap for C#ers just joining us: > > C# > int[] f = new int[3000000000]; > // compiles, throws System.OverflowException at run time > > VB.NET > Dim f(3000000000) As Integer > ' Will not compile: error is 'Constant expression not representable in > type Integer' > > So here, the VB.NET compiler can work out at compile time that 3 > billion is bigger than an Int32, and thus can't be used as an array > size (a CLS limitation I would suspect); but the C# compiler can't, or > doesn't care. > > Your particular example can be examined also: > > C# > long l = 3000000000; > int[] f = new int[l]; > // compiles, throws System.OverflowException at run time > > VB.NET > Dim l As Long = 3000000000 > Dim f(l) As Integer > ' Will not compile under Option Strict On: > ' error is 'Option Strict On disallows implicit conversions from > '<type1>' to '<type2>'' > ' WILL compile with Option Strict Off: throws System.OverflowException > at run time > > So for me the question is, why does C# allow this unstated cast from > long to int to compile? To that end I have xposted to the C# group creating a new array: (section 7.5.10.2 Array creation expressions) Each expression in the expression list must be of type int, uint, long, or ulong, or of a type that can be implicitly converted to one or more of these types It also says it's a compile-time error if a constant expression evaluates to a negative, but is silent about what happens if it evaluates to a number that's too large. In fact, nothing I can see in the spec refers to the largest possible size of an array being limited to what fits in an int. Apparently the language has no such restriction. Mike Schilling <ap@newsgroup.nospam> wrote:
Show quoteHide quote > > So for me the question is, why does C# allow this unstated cast from Having looked at the generated code, it looks like it will overflow on > > long to int to compile? To that end I have xposted to the C# group > > There's no cast involved; the C# spec says, regarding the sizes used in > creating a new array: (section 7.5.10.2 > Array creation expressions) > > Each expression in the expression list must be of type int, uint, long, > or ulong, or of a > type that can be implicitly converted to one or more of these types > > It also says it's a compile-time error if a constant expression evaluates to > a negative, but is silent about what happens if it evaluates to a number > that's too large. In fact, nothing I can see in the spec refers to the > largest possible size of an array being limited to what fits in an int. > Apparently the language has no such restriction. a 32-bit system, but not on a 64-bit system. A conv.of.i instruction is used, which converts to a native int and throws an exception if the value is too large to be stored in a native int. So, I think you could look at this in two ways. VB.NET stops you making silly mistakes on 32-bit systems, but prevents you from creating arrays of more than 2GB on 64-bit systems. C# does the reverse. Personally, on this matter I think I prefer the VB.NET approach. I'll raise this as a point of ambiguity in the spec though. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Mike Schilling <ap@newsgroup.nospam> wrote:
Show quoteHide quote > > So for me the question is, why does C# allow this unstated cast from Having looked at the generated code, it looks like it will overflow on > > long to int to compile? To that end I have xposted to the C# group > > There's no cast involved; the C# spec says, regarding the sizes used in > creating a new array: (section 7.5.10.2 > Array creation expressions) > > Each expression in the expression list must be of type int, uint, long, > or ulong, or of a > type that can be implicitly converted to one or more of these types > > It also says it's a compile-time error if a constant expression evaluates to > a negative, but is silent about what happens if it evaluates to a number > that's too large. In fact, nothing I can see in the spec refers to the > largest possible size of an array being limited to what fits in an int. > Apparently the language has no such restriction. a 32-bit system, but not on a 64-bit system. A conv.of.i instruction is used, which converts to a native int and throws an exception if the value is too large to be stored in a native int. So, I think you could look at this in two ways. VB.NET stops you making silly mistakes on 32-bit systems, but prevents you from creating arrays of more than 2GB on 64-bit systems. C# does the reverse. Personally, on this matter I think I prefer the VB.NET approach. I'll raise this as a point of ambiguity in the spec though. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too
Show quote
Hide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message Managed Array's (just like any other object)are limited to 2GB anyway, also news:MPG.1e9d749619e5851f98d03f@msnews.microsoft.com... | Mike Schilling <ap@newsgroup.nospam> wrote: | > > So for me the question is, why does C# allow this unstated cast from | > > long to int to compile? To that end I have xposted to the C# group | > | > There's no cast involved; the C# spec says, regarding the sizes used in | > creating a new array: (section 7.5.10.2 | > Array creation expressions) | > | > Each expression in the expression list must be of type int, uint, long, | > or ulong, or of a | > type that can be implicitly converted to one or more of these types | > | > It also says it's a compile-time error if a constant expression evaluates to | > a negative, but is silent about what happens if it evaluates to a number | > that's too large. In fact, nothing I can see in the spec refers to the | > largest possible size of an array being limited to what fits in an int. | > Apparently the language has no such restriction. | | Having looked at the generated code, it looks like it will overflow on | a 32-bit system, but not on a 64-bit system. A conv.of.i instruction is | used, which converts to a native int and throws an exception if the | value is too large to be stored in a native int. | | So, I think you could look at this in two ways. VB.NET stops you making | silly mistakes on 32-bit systems, but prevents you from creating arrays | of more than 2GB on 64-bit systems. C# does the reverse. Personally, on | this matter I think I prefer the VB.NET approach. | on 64bit windows. Willy.
Show quote
Hide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message Managed Array's (just like any other object)are limited to 2GB anyway, also news:MPG.1e9d749619e5851f98d03f@msnews.microsoft.com... | Mike Schilling <ap@newsgroup.nospam> wrote: | > > So for me the question is, why does C# allow this unstated cast from | > > long to int to compile? To that end I have xposted to the C# group | > | > There's no cast involved; the C# spec says, regarding the sizes used in | > creating a new array: (section 7.5.10.2 | > Array creation expressions) | > | > Each expression in the expression list must be of type int, uint, long, | > or ulong, or of a | > type that can be implicitly converted to one or more of these types | > | > It also says it's a compile-time error if a constant expression evaluates to | > a negative, but is silent about what happens if it evaluates to a number | > that's too large. In fact, nothing I can see in the spec refers to the | > largest possible size of an array being limited to what fits in an int. | > Apparently the language has no such restriction. | | Having looked at the generated code, it looks like it will overflow on | a 32-bit system, but not on a 64-bit system. A conv.of.i instruction is | used, which converts to a native int and throws an exception if the | value is too large to be stored in a native int. | | So, I think you could look at this in two ways. VB.NET stops you making | silly mistakes on 32-bit systems, but prevents you from creating arrays | of more than 2GB on 64-bit systems. C# does the reverse. Personally, on | this matter I think I prefer the VB.NET approach. | on 64bit windows. Willy. Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote:
> | So, I think you could look at this in two ways. VB.NET stops you making Hmm... that may be a limitation of .NET rather than the CLI spec > | silly mistakes on 32-bit systems, but prevents you from creating arrays > | of more than 2GB on 64-bit systems. C# does the reverse. Personally, on > | this matter I think I prefer the VB.NET approach. > > Managed Array's (just like any other object)are limited to 2GB anyway, also > on 64bit windows. though. The CLI spec states that the newarr instruction take a number of elements which is of type native int - and doesn't specify any limit. It could be that while current implementations have more restrictions, a future implementation may be able to create larger arrays. Of course, it could equally be two different people on the spec writing team who didn't talk to each other quite enough... -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote:
> | So, I think you could look at this in two ways. VB.NET stops you making Hmm... that may be a limitation of .NET rather than the CLI spec > | silly mistakes on 32-bit systems, but prevents you from creating arrays > | of more than 2GB on 64-bit systems. C# does the reverse. Personally, on > | this matter I think I prefer the VB.NET approach. > > Managed Array's (just like any other object)are limited to 2GB anyway, also > on 64bit windows. though. The CLI spec states that the newarr instruction take a number of elements which is of type native int - and doesn't specify any limit. It could be that while current implementations have more restrictions, a future implementation may be able to create larger arrays. Of course, it could equally be two different people on the spec writing team who didn't talk to each other quite enough... -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too
Show quote
Hide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message Actually it says "native int or int32", which is rather confusing IMO, and I news:MPG.1e9e0c647625a8d598d043@msnews.microsoft.com... | Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote: | > | So, I think you could look at this in two ways. VB.NET stops you making | > | silly mistakes on 32-bit systems, but prevents you from creating arrays | > | of more than 2GB on 64-bit systems. C# does the reverse. Personally, on | > | this matter I think I prefer the VB.NET approach. | > | > Managed Array's (just like any other object)are limited to 2GB anyway, also | > on 64bit windows. | | Hmm... that may be a limitation of .NET rather than the CLI spec | though. The CLI spec states that the newarr instruction take a number | of elements which is of type native int - and doesn't specify any | limit. | noticed that it's an int32 even on the 64-bit CLR. | It could be that while current implementations have more restrictions, Sure, it's a .NET limitation, it's possible that the next version of the CLR | a future implementation may be able to create larger arrays. | supports a larger value, but as far as I know nothing like this has been announced publically. | Of course, it could equally be two different people on the spec writing I don't think so. IMO the limitation is a conscious design decision. Imagine | team who didn't talk to each other quite enough... | what happens on a system when a single application allocates a single 8GB array (contigious memory) and starts to access it in a sparse/random order, you'll end in a world of pain unless you have a ton of physical memory available. Willy.
Show quote
Hide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message Actually it says "native int or int32", which is rather confusing IMO, and I news:MPG.1e9e0c647625a8d598d043@msnews.microsoft.com... | Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote: | > | So, I think you could look at this in two ways. VB.NET stops you making | > | silly mistakes on 32-bit systems, but prevents you from creating arrays | > | of more than 2GB on 64-bit systems. C# does the reverse. Personally, on | > | this matter I think I prefer the VB.NET approach. | > | > Managed Array's (just like any other object)are limited to 2GB anyway, also | > on 64bit windows. | | Hmm... that may be a limitation of .NET rather than the CLI spec | though. The CLI spec states that the newarr instruction take a number | of elements which is of type native int - and doesn't specify any | limit. | noticed that it's an int32 even on the 64-bit CLR. | It could be that while current implementations have more restrictions, Sure, it's a .NET limitation, it's possible that the next version of the CLR | a future implementation may be able to create larger arrays. | supports a larger value, but as far as I know nothing like this has been announced publically. | Of course, it could equally be two different people on the spec writing I don't think so. IMO the limitation is a conscious design decision. Imagine | team who didn't talk to each other quite enough... | what happens on a system when a single application allocates a single 8GB array (contigious memory) and starts to access it in a sparse/random order, you'll end in a world of pain unless you have a ton of physical memory available. Willy. Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote:
> | Hmm... that may be a limitation of .NET rather than the CLI spec Perhaps we're looking at different specs, or different places? I was > | though. The CLI spec states that the newarr instruction take a number > | of elements which is of type native int - and doesn't specify any > | limit. > > Actually it says "native int or int32", which is rather confusing IMO, and I > noticed that it's an int32 even on the 64-bit CLR. looking at partition 3 of the ECMA spec, in the definition of newarr. It's rather odd. > | It could be that while current implementations have more restrictions, Right. My guess is that in 10 years time the limitation might seem > | a future implementation may be able to create larger arrays. > > Sure, it's a .NET limitation, it's possible that the next version of the CLR > supports a larger value, but as far as I know nothing like this has been > announced publically. somewhat severe - although I would have thought that the spec could have been expanded at that time. > | Of course, it could equally be two different people on the spec writing But that situation may well be reasonably common in 10 years.> | team who didn't talk to each other quite enough... > > I don't think so. IMO the limitation is a conscious design decision. Imagine > what happens on a system when a single application allocates a single 8GB > array (contigious memory) and starts to access it in a sparse/random order, > you'll end in a world of pain unless you have a ton of physical memory > available. Put it this way - future expansion is the only reason I can see for array lengths being allowed to be longs in C#. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote:
> | Hmm... that may be a limitation of .NET rather than the CLI spec Perhaps we're looking at different specs, or different places? I was > | though. The CLI spec states that the newarr instruction take a number > | of elements which is of type native int - and doesn't specify any > | limit. > > Actually it says "native int or int32", which is rather confusing IMO, and I > noticed that it's an int32 even on the 64-bit CLR. looking at partition 3 of the ECMA spec, in the definition of newarr. It's rather odd. > | It could be that while current implementations have more restrictions, Right. My guess is that in 10 years time the limitation might seem > | a future implementation may be able to create larger arrays. > > Sure, it's a .NET limitation, it's possible that the next version of the CLR > supports a larger value, but as far as I know nothing like this has been > announced publically. somewhat severe - although I would have thought that the spec could have been expanded at that time. > | Of course, it could equally be two different people on the spec writing But that situation may well be reasonably common in 10 years.> | team who didn't talk to each other quite enough... > > I don't think so. IMO the limitation is a conscious design decision. Imagine > what happens on a system when a single application allocates a single 8GB > array (contigious memory) and starts to access it in a sparse/random order, > you'll end in a world of pain unless you have a ton of physical memory > available. Put it this way - future expansion is the only reason I can see for array lengths being allowed to be longs in C#. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too
Show quote
Hide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message From ECMA-335 3rd Ed. / June2005news:MPG.1e9e3659df1860f198d046@msnews.microsoft.com... | Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote: | > | Hmm... that may be a limitation of .NET rather than the CLI spec | > | though. The CLI spec states that the newarr instruction take a number | > | of elements which is of type native int - and doesn't specify any | > | limit. | > | > Actually it says "native int or int32", which is rather confusing IMO, and I | > noticed that it's an int32 even on the 64-bit CLR. | | Perhaps we're looking at different specs, or different places? I was | looking at partition 3 of the ECMA spec, in the definition of newarr. | It's rather odd. | Partition III 4.20 newarr - ..... .... The newarr instruction pushes a reference to a new zero-based, one-dimensional array whose elements are of type etype, a metadata token (a typeref, typedef or typespec; see Partition II). numElems (of type native int or int32) specifies the number of elements in the array. Valid array indexes are 0 ? index < numElems ... Show quoteHide quote | > | It could be that while current implementations have more restrictions, Well I don't believe so, but I could be wrong :-(.| > | a future implementation may be able to create larger arrays. | > | > Sure, it's a .NET limitation, it's possible that the next version of the CLR | > supports a larger value, but as far as I know nothing like this has been | > announced publically. | | Right. My guess is that in 10 years time the limitation might seem | somewhat severe - although I would have thought that the spec could | have been expanded at that time. | | > | Of course, it could equally be two different people on the spec writing | > | team who didn't talk to each other quite enough... | > | > I don't think so. IMO the limitation is a conscious design decision. Imagine | > what happens on a system when a single application allocates a single 8GB | > array (contigious memory) and starts to access it in a sparse/random order, | > you'll end in a world of pain unless you have a ton of physical memory | > available. | | But that situation may well be reasonably common in 10 years. | I remember back in 1995 DEC said that at the end of the century 30% of all the server/desktop would be equiped with one or more 64-bit processors with at least 16GB of RAM, running a 64 bit OS. Six years later the world looks more conservative with less than 10% market share (estimates) for 64 bit HW and an avarage of 8GB of RAM. | Put it this way - future expansion is the only reason I can see for Agreed, but I would be happy if they first relaxed the 2GB restriction, this | array lengths being allowed to be longs in C#. | way we would be able to create 2^31 * sizeof(long) arrays or 16GB, without a need to change the CLR data structures. Willy.
Show quote
Hide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message From ECMA-335 3rd Ed. / June2005news:MPG.1e9e3659df1860f198d046@msnews.microsoft.com... | Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote: | > | Hmm... that may be a limitation of .NET rather than the CLI spec | > | though. The CLI spec states that the newarr instruction take a number | > | of elements which is of type native int - and doesn't specify any | > | limit. | > | > Actually it says "native int or int32", which is rather confusing IMO, and I | > noticed that it's an int32 even on the 64-bit CLR. | | Perhaps we're looking at different specs, or different places? I was | looking at partition 3 of the ECMA spec, in the definition of newarr. | It's rather odd. | Partition III 4.20 newarr - ..... .... The newarr instruction pushes a reference to a new zero-based, one-dimensional array whose elements are of type etype, a metadata token (a typeref, typedef or typespec; see Partition II). numElems (of type native int or int32) specifies the number of elements in the array. Valid array indexes are 0 ? index < numElems ... Show quoteHide quote | > | It could be that while current implementations have more restrictions, Well I don't believe so, but I could be wrong :-(.| > | a future implementation may be able to create larger arrays. | > | > Sure, it's a .NET limitation, it's possible that the next version of the CLR | > supports a larger value, but as far as I know nothing like this has been | > announced publically. | | Right. My guess is that in 10 years time the limitation might seem | somewhat severe - although I would have thought that the spec could | have been expanded at that time. | | > | Of course, it could equally be two different people on the spec writing | > | team who didn't talk to each other quite enough... | > | > I don't think so. IMO the limitation is a conscious design decision. Imagine | > what happens on a system when a single application allocates a single 8GB | > array (contigious memory) and starts to access it in a sparse/random order, | > you'll end in a world of pain unless you have a ton of physical memory | > available. | | But that situation may well be reasonably common in 10 years. | I remember back in 1995 DEC said that at the end of the century 30% of all the server/desktop would be equiped with one or more 64-bit processors with at least 16GB of RAM, running a 64 bit OS. Six years later the world looks more conservative with less than 10% market share (estimates) for 64 bit HW and an avarage of 8GB of RAM. | Put it this way - future expansion is the only reason I can see for Agreed, but I would be happy if they first relaxed the 2GB restriction, this | array lengths being allowed to be longs in C#. | way we would be able to create 2^31 * sizeof(long) arrays or 16GB, without a need to change the CLR data structures. Willy. Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote:
Show quoteHide quote > | Perhaps we're looking at different specs, or different places? I was Ah, interesting - same bit, different version. I'm looking at the 2002 > | looking at partition 3 of the ECMA spec, in the definition of newarr. > | It's rather odd. > > From ECMA-335 3rd Ed. / June2005 > > Partition III > > 4.20 newarr - ..... > ... > The newarr instruction pushes a reference to a new zero-based, > one-dimensional array whose elements are of type etype, a metadata token (a > typeref, typedef or typespec; see Partition II). numElems (of type native > int or int32) specifies the number of elements in the array. Valid array > indexes are 0 ? index < numElems ... version. That "or" is really confusing - I have no idea what it means. > | But that situation may well be reasonably common in 10 years. Of course DEC was trying to sell Alphas at the time :)> | > Well I don't believe so, but I could be wrong :-(. > I remember back in 1995 DEC said that at the end of the century 30% of all > the server/desktop would be equiped with one or more 64-bit processors with > at least 16GB of RAM, running a 64 bit OS. Six years later the world looks > more conservative with less than 10% market share (estimates) for 64 bit HW > and an avarage of 8GB of RAM. While it's true that we're not in a situation where more than 8GB is *common*, it's starting to happen every so often, and not only in massive organisations. Machines with 1 or 2GB are more common for consumers than they were - certainly for developers, and things do tend to gradually push upwards. Of course, there's the ever-tantalising prospect of fast, massive, cheap static memory - the "1TB on a credit card sized form factor for $50" promise. I'll believe it when I see it - but if it ever *does* happen, computing will change drastically... > | Put it this way - future expansion is the only reason I can see for Right.> | array lengths being allowed to be longs in C#. > > Agreed, but I would be happy if they first relaxed the 2GB restriction, this > way we would be able to create 2^31 * sizeof(long) arrays or 16GB, without a > need to change the CLR data structures. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote:
Show quoteHide quote > | Perhaps we're looking at different specs, or different places? I was Ah, interesting - same bit, different version. I'm looking at the 2002 > | looking at partition 3 of the ECMA spec, in the definition of newarr. > | It's rather odd. > > From ECMA-335 3rd Ed. / June2005 > > Partition III > > 4.20 newarr - ..... > ... > The newarr instruction pushes a reference to a new zero-based, > one-dimensional array whose elements are of type etype, a metadata token (a > typeref, typedef or typespec; see Partition II). numElems (of type native > int or int32) specifies the number of elements in the array. Valid array > indexes are 0 ? index < numElems ... version. That "or" is really confusing - I have no idea what it means. > | But that situation may well be reasonably common in 10 years. Of course DEC was trying to sell Alphas at the time :)> | > Well I don't believe so, but I could be wrong :-(. > I remember back in 1995 DEC said that at the end of the century 30% of all > the server/desktop would be equiped with one or more 64-bit processors with > at least 16GB of RAM, running a 64 bit OS. Six years later the world looks > more conservative with less than 10% market share (estimates) for 64 bit HW > and an avarage of 8GB of RAM. While it's true that we're not in a situation where more than 8GB is *common*, it's starting to happen every so often, and not only in massive organisations. Machines with 1 or 2GB are more common for consumers than they were - certainly for developers, and things do tend to gradually push upwards. Of course, there's the ever-tantalising prospect of fast, massive, cheap static memory - the "1TB on a credit card sized form factor for $50" promise. I'll believe it when I see it - but if it ever *does* happen, computing will change drastically... > | Put it this way - future expansion is the only reason I can see for Right.> | array lengths being allowed to be longs in C#. > > Agreed, but I would be happy if they first relaxed the 2GB restriction, this > way we would be able to create 2^31 * sizeof(long) arrays or 16GB, without a > need to change the CLR data structures. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too
Show quote
Hide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message Nor do I.news:MPG.1e9e43a8ef5f1d5d98d049@msnews.microsoft.com... | Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote: | > | Perhaps we're looking at different specs, or different places? I was | > | looking at partition 3 of the ECMA spec, in the definition of newarr. | > | It's rather odd. | > | > From ECMA-335 3rd Ed. / June2005 | > | > Partition III | > | > 4.20 newarr - ..... | > ... | > The newarr instruction pushes a reference to a new zero-based, | > one-dimensional array whose elements are of type etype, a metadata token (a | > typeref, typedef or typespec; see Partition II). numElems (of type native | > int or int32) specifies the number of elements in the array. Valid array | > indexes are 0 ? index < numElems ... | | Ah, interesting - same bit, different version. I'm looking at the 2002 | version. That "or" is really confusing - I have no idea what it means. | Show quoteHide quote | > | But that situation may well be reasonably common in 10 years. Yep ,not that we expected to take that 30% with Alpha (our estimate was 6%), | > | | > Well I don't believe so, but I could be wrong :-(. | > I remember back in 1995 DEC said that at the end of the century 30% of all | > the server/desktop would be equiped with one or more 64-bit processors with | > at least 16GB of RAM, running a 64 bit OS. Six years later the world looks | > more conservative with less than 10% market share (estimates) for 64 bit HW | > and an avarage of 8GB of RAM. | | Of course DEC was trying to sell Alphas at the time :) | but their forcasts were backed by Gartner's. | While it's true that we're not in a situation where more than 8GB is True, however we may not forget that we are talking about single array's of | *common*, it's starting to happen every so often, and not only in | massive organisations. Machines with 1 or 2GB are more common for | consumers than they were - certainly for developers, and things do tend | to gradually push upwards. | | Of course, there's the ever-tantalising prospect of fast, massive, | cheap static memory - the "1TB on a credit card sized form factor for | $50" promise. I'll believe it when I see it - but if it ever *does* | happen, computing will change drastically... | 2GB, so you can have several of these monsters in a single AD and multiple AD's per process and that can become a real issue even on 64 bit if you don't set a limit. One of the major problems we encounter now (on 64-bit) are an overuse of XML and self expanding ArrayLists and generic List's in server applications, growing beyong available HW memory, just because "they are so easy to use sir". OOM exceptions aren't thrown any longer, but oh, the performance drops dramatically and developper don't understand why. So IMO it's good to have some limits, it makes people think, but I guess it's me getting old ;-). Willy.
Show quote
Hide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message Nor do I.news:MPG.1e9e43a8ef5f1d5d98d049@msnews.microsoft.com... | Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote: | > | Perhaps we're looking at different specs, or different places? I was | > | looking at partition 3 of the ECMA spec, in the definition of newarr. | > | It's rather odd. | > | > From ECMA-335 3rd Ed. / June2005 | > | > Partition III | > | > 4.20 newarr - ..... | > ... | > The newarr instruction pushes a reference to a new zero-based, | > one-dimensional array whose elements are of type etype, a metadata token (a | > typeref, typedef or typespec; see Partition II). numElems (of type native | > int or int32) specifies the number of elements in the array. Valid array | > indexes are 0 ? index < numElems ... | | Ah, interesting - same bit, different version. I'm looking at the 2002 | version. That "or" is really confusing - I have no idea what it means. | Show quoteHide quote | > | But that situation may well be reasonably common in 10 years. Yep ,not that we expected to take that 30% with Alpha (our estimate was 6%), | > | | > Well I don't believe so, but I could be wrong :-(. | > I remember back in 1995 DEC said that at the end of the century 30% of all | > the server/desktop would be equiped with one or more 64-bit processors with | > at least 16GB of RAM, running a 64 bit OS. Six years later the world looks | > more conservative with less than 10% market share (estimates) for 64 bit HW | > and an avarage of 8GB of RAM. | | Of course DEC was trying to sell Alphas at the time :) | but their forcasts were backed by Gartner's. | While it's true that we're not in a situation where more than 8GB is True, however we may not forget that we are talking about single array's of | *common*, it's starting to happen every so often, and not only in | massive organisations. Machines with 1 or 2GB are more common for | consumers than they were - certainly for developers, and things do tend | to gradually push upwards. | | Of course, there's the ever-tantalising prospect of fast, massive, | cheap static memory - the "1TB on a credit card sized form factor for | $50" promise. I'll believe it when I see it - but if it ever *does* | happen, computing will change drastically... | 2GB, so you can have several of these monsters in a single AD and multiple AD's per process and that can become a real issue even on 64 bit if you don't set a limit. One of the major problems we encounter now (on 64-bit) are an overuse of XML and self expanding ArrayLists and generic List's in server applications, growing beyong available HW memory, just because "they are so easy to use sir". OOM exceptions aren't thrown any longer, but oh, the performance drops dramatically and developper don't understand why. So IMO it's good to have some limits, it makes people think, but I guess it's me getting old ;-). Willy. Yea seems like at some point VB.NET is smarter or strict here... I took all
the trouble to move from VB to C# over last 2 years.. now you have given me some reason to come back.. :-) Actually speaking I should be a loyalist here for VB, because my initials are VB...:-) Show quoteHide quote "Vijay" <vi***@msdiscussions.com> wrote in message news:uw3kCB$VGHA.5588@TK2MSFTNGP09.phx.gbl... > The confusion for me here is C-Sharp does not seem to complain. VB being > simple enough why is there this problem? Maybe they have not changed the > underlying type from VB?? > > VJ > > <za***@construction-imaging.com> wrote in message > news:1143841803.101695.88850@z34g2000cwc.googlegroups.com... >> The length of an array is defined as a 32-bit integer. The Length >> property in the FileStream class is a Long. Convert it to an Int, but >> you should really check to see if the length of the file yo are trying >> to read isn't too large to fit in a 32-bit int. >> > > Vijay,
In addition to Renze. VB has very simple convert methods. Dim buffer(CInt(fs.Length)) As Byte ' I hope this helps, Cor Show quoteHide quote "Vijay" <vi***@msdiscussions.com> schreef in bericht news:OEf2EfQVGHA.2360@TK2MSFTNGP09.phx.gbl... > With the option strict On set..... > > Dim fs As FileStream = File.OpenRead(strFile) > > With fs > Dim buffer(fs.Length) As Byte ' <--- Option Strict On disallows implicit > conversions from 'Long' to 'Integer'. > ' other stuff.. > End With > > been a while i did VB code... can somebody help me what I am doing wrong > here... > > Vijay > 
Other interesting topics
Get the selected value from a listbox
disabling controls by checking off a radio button when the form loads Can't close EXCEL from my VB.NET application Passing a Variable from one web site to another for ASP Importing from Excel ContainsFocus equivalent in VB SENDMail Use active directory to scan for software on a remote system? Get Memory Usage of my Program How do i do this in VB .Net |
|||||||||||||||||||||||
