Returning value, Array Bounds

B

bri189a

Senior Contributor
Joined
Sep 11, 2003
Messages
1,004
Location
VA
Couple more questions, I'm use to:

string DoSomething()
{
// return code...
return x;
}

in a function, VB has allowed me to do that, but is that legacy VB6 or is:

Function DoSomething() As String
'return code
DoSomething = x
End Function

the prefered way.

And with arrays, I've been doing in C# and transposing into VB
for(int i = 0;i<z.Length;i++)
{//Code}

Should I be using UpperBound and LowerBound instead? Which method is perferred by DotNet?
 
I would go with Length since Length is a property, while upperbound and lowerbound are functions.
However, you can assign the result of GetUpperBound to a variable and use the variable in the for loop.

If the size of the array will change in the For Loop, I would use GetUpperBound. Otherwise, go for Length - 1.
The LowerBound is always 0. I have yet to see an exception to this. :)
 
I found this in MSDN, does this relate to something else, I'm assuming it does, using Return to return from a function as you do in C# seems the most .NET preferred method:

GoSub and Return statements are not supported in Visual Basic .NET. In most cases you can replace these with functions and procedures.

Also PD, I know you stated to not use CInt, CDbl, CSng, etc., do you have any documentation backing up the reasoning... just in case I butt heads with someone... I agree with your reasoning on that post, but not everybody else will. In MSDN they come up when you search for Type Conversions and/or casting and I have a feeling I will end up butting heads with someone on it... if you have docs that say it calls VB6 run-time dll's, then I have a leg to stand on.

Thanks!
 
As long as you do not use Gosub in VB, you can use Return safely.
In a function you can use Return to return a value:
Return ab + bc
In a sub, Return will just kick you out.

It is good practice to have only one Return in a Function or Subroutine and this Return would be at the end.

And anything that you find in the Microsoft.VisualBasic namespace is part of the backwards compatibility. :)
 
Iceplug said:
And anything that you find in the Microsoft.VisualBasic namespace is part of the backwards compatibility. :)
Click to expand...

Woah!!! Hold on... while it is true that any functionality found in the Microsoft.VisualBasic namespace can almost always be reproduced by classes in other namespaces and I personally recommend using non-Visual Basic methods for portability and readability (for those who use c# or any other .net languages), I am under the impression that the VisualBasic namespace is still considered part of the Visual Basic language, not just for backwards compatability. The VisualBasic namespace is certainly never going to be obsoleted or depreciated as a whole as long as Visual Basic is around!

While there are reasons why one might want to avoid the VisualBasic namespace there are also reasons why one might prefer the VisualBasic namespace... for instance if you want your code to be more portable between VB6 and VB.Net. It is a matter of circumstance and preference.
 
marble_eater said:
or instance if you want your code to be more portable between VB6 and VB.Net.
Click to expand...
Now why in the world would you want VB.NET code to be backwards compatibile with VB6? :) You are not thinking about "porting" programs to VB6 are you? ;)
 
mutant said:
Now why in the world would you want VB.NET code to be backwards compatibile with VB6? :) You are not thinking about "porting" programs to VB6 are you? ;)
Click to expand...

I have never found myself porting more than a few lines of .Net code to VB6 code. But consider the rare but possible circumstances of two companies (or even two amateur programmers) who already have two different versions of Visual Basic and do not plan on swiching versions but would like to share code. Or, what if you begin writing a program in VB.Net and decide to switch to VB6 because it consumes less memory, or if you have a large base of preexisting VB6 code and a small amount of .Net code you want to use in a project you are creating, in which case it would be easier to port the .Net code.

Like I said... I try to stay away from the VisualBasic namespace. But there may be reasons to stick to the Visual Basic runtime libraries in some cases. I wouldn't want to put myself into a situation where I had to port a large amount of file parsing code that uses the StreamReader class... or a configuration management class that uses the RegistryKey classes.

Edit:

...or what if you wanted to turn .Net UserControls into ActiveX controls...
 
Last edited:
Back
Top