I use me.obj because intellisense can help you save keystrokes and avoid mispellings.
as I understand it (and this takes me back a little) in C++, OO cobol and simmilliar langauges you could get a method to compile withthe object rather than have all the objects share that method compiled once withthe base during initial instantiation. in that case you could specify that you meant the local method. i think. it's been a while. I do recall that it was only nessecarry when dealing with dynamic data, and only in certian cases.
and also this->ptr == ...
looks better than
ptr* == ...
just my 2 bits and don't take it as bible verse. as I said...it's been a while
It's really only necessary if there are multiple objects with the same name, but different scopes, all available to the same routine. Then you may need to use This (Me) in order to get the correct object.
For instance:
Let's say you have a Form called Form1 with a TextBox called TextBox1 added to it at design time. You could then go into an procedure within Form1, say Form1.Load, and declare a variable named TextBox1:
Private Sub Form1_Load()
Dim TextBox1 as String
End Sub
Now when you type only TextBox1 you will be accessing the string variable, whereas Me.TextBox1 will access the TextBox object on the Form:
Private Sub Form1_Load()
Dim TextBox1 as String
'Set Label1.Text to the text in the local string variable Label1.Text = TextBox1.ToString()
'Set Label2.Text to the text in the textbox on the form Label2.Text = Me.TextBox1.Text.ToString()
End Sub
I don't think there is an impact at runtime becuase the complier has already translated this line of code.
Is using this.object (C#) or me.object (Vb)more efficient?
Is using this.object (C#) or me.object (Vb)more efficient?
gunsen
as I understand it (and this takes me back a little) in C++, OO cobol and simmilliar langauges you could get a method to compile withthe object rather than have all the objects share that method compiled once withthe base during initial instantiation. in that case you could specify that you meant the local method. i think. it's been a while. I do recall that it was only nessecarry when dealing with dynamic data, and only in certian cases.
and also
this->ptr == ...
looks better than
ptr* == ...
just my 2 bits
and don't take it as bible verse. as I said...it's been a while
KipB
yngielkoh
Pravin Chandankhede
For instance:
Let's say you have a Form called Form1 with a TextBox called TextBox1 added to it at design time. You could then go into an procedure within Form1, say Form1.Load, and declare a variable named TextBox1:
Private Sub Form1_Load()
Dim TextBox1 as String
End Sub
Now when you type only TextBox1 you will be accessing the string variable, whereas Me.TextBox1 will access the TextBox object on the Form:
Private Sub Form1_Load()
Dim TextBox1 as String
'Set Label1.Text to the text in the local string variable
Label1.Text = TextBox1.ToString()
'Set Label2.Text to the text in the textbox on the form
Label2.Text = Me.TextBox1.Text.ToString()
End Sub
I don't think there is an impact at runtime becuase the complier has already translated this line of code.