By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,733 Members | 889 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,733 IT Pros & Developers. It's quick & easy.

"Call" function ?

P: n/a

I have a function named

getID3info (lvwDiscInfo.SelectedItem).

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 ?

Thanks.
Alias
Jul 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Thu, 03 Jul 2003 04:34:37 GMT, Alias <-@-.> wrote:
[ oops....here is the correct function name]


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 ?

Thanks.
Alias

Jul 17 '05 #2

P: n/a
> 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
Jul 17 '05 #3

P: n/a
On Thu, 3 Jul 2003 01:42:16 -0400, "Rick Rothstein"
<ri************@NOSPAMcomcast.net> wrote:

Rick,
Thanks for the detailed reply. More responses in the copy below.

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.


Yes, you are right. I'm revisiting some code I wrote when I was an
absolute beginner - the function (which reads ID3 info from an MP3)
was probably a cut and paste from some web sample code.

I've changed it to a Sub, since, as you point out, no value is
returned. I've also modified the syntax as advised.
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.
Ok - understood.
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.
I see. Interesting.
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.
Got it.
I went ahead and tested option 3:

Private Sub Command2_Click()
DeleteText Text1
End Sub

and sure enough, it cleared the textbox.
Hope the above helped.
Very much so - I'm glad I asked.
Rick - MVP
Thanks
Alias


Jul 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.