> I have a function named
Public Function getID3info(ByRef x As String) As Integer
What is the difference between
getID3info (lvwDiscInfo.SelectedItem)
and
Call getID3info(lvwDiscInfo.SelectedItem) ?
They both work properly - is there some kind of runtime overhead
difference between the two ?
First off, VB has two types of procedures, a Sub and a Function. A Sub
simply executes codes, a Function does the same thing; but, in addition, it
also returns a value. You declared your procedure as a Function, but the two
methods you ask your question about do not show any value being accepted by
the calling routine. Given that, I'd suggest you declare your sample
procedure as a Sub instead. A Function can be used as a Sub, but you are
wasting the memory location that is supposed to hold the return value.
Now, as to your question... whenever you use parentheses around something
that is not part of the syntax, VB evaluates the expression contained inside
(even if there is nothing to "calculate"). The parentheses in the line with
the Call keyword are part of the syntax, so the (assumed) Sub receives the
arguments ByRef as declared. However, in the other statement, the
parentheses are **not** part of the syntax (see the Remarks section of the
Help files for the Call statement). That means VB evaluates the single
expression it finds enclosed within. It does that by establishing a
temporary memory location in which to carry at the evaluation and passes a
pointer to the evaluated contents at that memory address. This means the Sub
has access to the actual argument being passed by the Call statement and can
modify its value in the calling code's procedure; in the other statement,
the Sub has no access to the argument at all and cannot affect its value
back in the calling procedure. I'd say the reason both expressions work
properly is because you are not changing the value of the argument within
the Sub.
A quick example...
Private Sub Form_Load()
Dim SomeInteger As Integer
SomeInteger = 1
Debug.Print SomeInteger & " <== original value"
AddFive (SomeInteger)
Debug.Print SomeInteger & " <== didn't change"
Call AddFive(SomeInteger)
Debug.Print SomeInteger & " <== this time, it changed"
AddFive SomeInteger
Debug.Print SomeInteger & " <== no parens, it changed again"
End Sub
Sub AddFive(NumberIn As Integer)
NumberIn = NumberIn + 5
End Sub
Start a new project and paste the above code into the form's code window;
Run the program.
The misuse of parentheses can also generate errors when dealing with
objects. Start a new project and add a TextBox and two(2) CommandButtons and
paste this code into the form's code window
Private Sub Command1_Click()
Call DeleteText(Text1)
End Sub
Private Sub Command2_Click()
DeleteText (Text1)
End Sub
Sub DeleteText(TBox As TextBox)
TBox.Text = ""
End Sub
Run the project, type some text into the TextBox and click Command1. The
text is deleted as expected. Now type some more text into the TextBox and
click Command2. Whoops... an error. Why? Because when you put the
parentheses around that Text1 object, but did not use the Call keyword, you
forced VB to evaluate the Text1 object. TextBoxes have a default property of
Text (the characters making up the content of the TextBox) and it was a
pointer to the temporary memory address VB copied the contents of Text1 to
that was passed. Since this is a String, and not a TextBox object, VB
generated a Type Mismatch error.
Hope the above helped.
Rick - MVP
