VB6 commands and equivalent VB.NET methods

kulrom

Well-known member
Joined
May 10, 2005
Messages
2,854
Location
Republic of Macedonia
Programming Experience
10+
Hi, All I want to say is that you just have to actually remove the reference to the Microsoft.VisualBasic assembly from a VB.NET project.

I'm telling this becuase I still find way too many developers writing VB6 code in .NET (or they are using the overdated code found through internet without consider its quality).

I know old habits are hard to break, but come on people, let’s do things the .NET way. In particular, I’m referring to all the VB6 methods that have equivalent .NET methods, such as UCase, LCase, Left, Mid, Right, UBound, Len, LTrim, RTrim, CStr, CInt, etc. – the list goes on and on.

For instance, consider these VB 6 Commands and their equivalents:
Len = .Length
Mid = .SubString
Replace = .Replace
InStr = .IndexOf
UCase = .ToUpper
LCase = .ToLower
Split = .Split
Join = .Join


Cheers ;)
 
I'm in the process of compiling a list of replacements for all VB Runtime functions for another location. I will post it here also when I'm done. Let me say this though: VB Runtime functions are NOT evil. I do agree that an alternative from a System-based namespace should be used where possible, but there are certain Runtime functions that have no replacement in .NET 1.1, like IsDate and Beep. Also Kulrom, you have made a mistake that many do in assuming that CStr, CInt, etc. are Runtime functions. They are not, but are in fact an in-built part of the VB.NET language. Notice that they turn blue when you type them, as do all VB.NET key words. CType actually calls CStr, CInt, etc. when passed the appropriate type. If you aren't aware what are VB Runtime functions and what aren't then removing the MS.VB reference can ceratinly highlight them for you, but you will also lose some useful functions that do not have genuine replacements in the System namespace.
 
As you might say Kulrom, settle down. If you read my post you'll see that I believe it is a good idea to avoid VB Runtime functions if possible. I'm also saying that using them is not the crime against humanity that many, including myself in the past, believe it to be. I already know what is a Runtime function and what isn't so there's no need for me to remove that reference to find out. The only genuine problem with using Runtime functions is that Microsoft may drop support for some or all of the Microsoft.VisualBasic namespace in the future. There is no specific eveidence that this is going to happen though. I think that all developers should get to know as much about their chosen language as possible, so anyone who has been using VB.NET for some time and doesn't know the difference between a Runtime function and a System-based function has been, in my opinion, very slack. To say it is using VB6 is incorrect though, because while the functions have been named to mimic VB6 functions and they behave essentially the same, they are 100% implemented in VB.NET. For instance, I have read on MSDN that IsDate is implemented very much like this:
VB.NET:
Public Function IsDate(ByVal Expression As Object) As Boolean
	Try
		Date.Parse(Expression)
		Return True
	Catch e As Exception
		Return False
	End Try
End Function
Let me conclude by saying that I would encourage all VB.NET developers to learn as much about the language as possible and use a System-based function where a suitable one exists. Removing the reference to the Microsoft.VisualBasic namespace from your project can be a good way to force yourself to do that, but you will be throwing out a bit of the baby with that bathwater.
 
This is surely an interesting discussion. I myself have been trying to implement it the .Net way as much as I can. However, I noticed that doing it the .Net way might somehow increase coding (or I do not not how to implement it well). For example:
VB.NET:
[color=Blue]Dim [/color]strTest [color=Blue]As String[/color]
MessageBox.Show(Len(strTest))
MessageBox.Show(strTest.Length)
The first messagebox comes out with '0', but the second one returns an error: Object reference not set to an instance of an object.

I do not know, but for me to avoid the error I need to code it as:
VB.NET:
[color=Blue]Dim [/color]strTest [color=Blue]As String [color=Black]= ""[/color][/color]
However, that doesn't seem elegant and is a bit messy... I wonder why does .Net treat "" as something instead of Nothing
 
I suggest that everyone always read the help topic for every class, method, property or field they use. A String object is an instance of a class, so you must create an instance before you can use its members, just like any class. The Len() function takes this into account. It is partially implemented like this:
VB.NET:
If Expression Is Nothing
	Return 0
ElseIf TypeOf Expression Is String
	Return DirectCast(Expression, String).Length
This is an example of a Runtime function providing extra functionality that you would normally have to provide yourself, although it is important to realise that your string may still be a null reference and you still cannot use any of its properties for any purpose.

Many people mistakenly believe that a string variable is a value-type object, like an Integer. It is in fact a reference-type object, so you must assign an object to the variable before you can use its members. The reason that a string behaves quite similarly to a value-type is because it is an immutable object, i.e. once set it cannot be changed. If you ever make any changes to a string variable you are actually creating a whole new object and assigning it to the variable, rather than changing the existing object that the variable currently refers to. Also, if you try to display any null reference it will be displayed as an empty string. This is because any null reference converted to a String becomes an empty string. This helps to reinforce the misconception. The String class has been designed to function much like a value-type because they are used so much it makes them more convenient, but it is important to remember that they are actually reference-types and to treat them accordingly. Try this code and see if you understand what's happening:
VB.NET:
		Dim str As String

		MessageBox.Show((str Is Nothing).ToString) 'Check if string is nothing
		MessageBox.Show((str = Nothing).ToString) 'Check if string equals nothing

		str = String.Empty

		MessageBox.Show((str Is Nothing).ToString)
		MessageBox.Show((str = Nothing).ToString)
 
Yes... thanks, I can see the difference.

Hope you can bear with me coz beginners commonly are obsessive/compulsive to get their code perfected :). I've come out with a few variations to implement it the .Net way, which are as follows:

VB.NET:
[color=Blue]Dim [/color]strTest0 [color=Blue]As String[/color] = [color=Blue]String[/color].Empty
MessageBox.Show(strTest0.Length)

[color=Blue]Dim [/color]strTest1 [color=Blue]As New String[/color]([color=Blue]String[/color].Empty)
MessageBox.Show(strTest1.Length)

[color=Blue]Dim [/color]strTest2 [color=Blue]As String[/color]
strTest2 = [color=Blue]String[/color].Empty
MessageBox.Show(strTest2.Length)

[color=Blue]Dim [/color]strTest3 [color=Blue]As String[/color]
[color=Blue]If [/color]strTest3 [color=Blue]Is Nothing Then[/color]
	MessageBox.Show("0")
[color=Blue]Else[/color]
	MessageBox.Show(strTest3.Length)
[color=Blue]End If[/color]

... and the shortest way is the 'strTest0'. Though I think that it is faster to use Len straightaway for it's ease of use, but as you said, we cannot be sure how long this function will be supported by the next .Net
 
The first thing you do with any variable should be assigning something to it. If you know that you are creating this string variable to accept the result of some function then initialising it is not necessary, but otherwise it is good practice to initialise it as you have in your first example. Even value-type variables, e.g. Integers, Doubles, Booleans, etc., should be treated the same way. C# actually enforces this but VB is still more lax. If you don't initialise Integer variables, for instance, then how does someone looking at the code know whether you want them to be zero or you just forgot to assign some other value?

Getting back more towards Kulrom's original topic, we cannot be sure how long anything will be supported. Just because you avoid Runtime functions doesn't mean that your code won't become obsolete. Certain things will almost certainly never disappear, like String.Length, but some entire namespaces have been deprecated in .NET 2.0, like System.Web.Mail. Also, things like the MainMenu and Toolbar have been replaced with better controls. The old ones are still there for compatibility but for how long?
 
Equivalent for Step by Step Debuging (F8) of VB6 in VB.net

Can any one tell me how to execute step by step execution in VB.net as we did in debuging in VB6 by Function KeyF8
 
Aiby said:
Can any one tell me how to execute step by step execution in VB.net as we did in debuging in VB6 by Function KeyF8
Although that's not really related to the original question, I think you're looking for F10. F10 steps to the next line in the current context, F11 steps into the next property or method and Shift+F11 steps out of the current context and back to the caller.

Edit:
You can also use the Debug menu, where the F10 shortcut is displayed, or the toolbar.
 
I'm in the process of compiling a list of replacements for all VB Runtime functions for another location. I will post it here also when I'm done. Let me say this though: VB Runtime functions are NOT evil. I do agree that an alternative from a System-based namespace should be used where possible, but there are certain Runtime functions that have no replacement in .NET 1.1, like IsDate and Beep. Also Kulrom, you have made a mistake that many do in assuming that CStr, CInt, etc. are Runtime functions. They are not, but are in fact an in-built part of the VB.NET language. Notice that they turn blue when you type them, as do all VB.NET key words. CType actually calls CStr, CInt, etc. when passed the appropriate type. If you aren't aware what are VB Runtime functions and what aren't then removing the MS.VB reference can ceratinly highlight them for you, but you will also lose some useful functions that do not have genuine replacements in the System namespace.

jmcilhinney,
Ever get this list done?
Thanks,
schemer
 
Back
Top