"Call" function ?

Re: "Call&quot ; function ?

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

I have a function named

Public Function getID3info(ByRe f x As String) As Integer

What is the difference between

getID3info (lvwDiscInfo.Se lectedItem)
and
Call getID3info(lvwD iscInfo.Selecte dItem) ?

They both work properly - is there some kind of runtime overhead
difference between the two ?

Thanks.
¤ Alias

Re: &quot;Call&quot ; function ?

> I have a function named[color=blue]
>
> Public Function getID3info(ByRe f x As String) As Integer
>
> What is the difference between
>
> getID3info (lvwDiscInfo.Se lectedItem)
> and
> Call getID3info(lvwD iscInfo.Selecte dItem) ?
>
> They both work properly - is there some kind of runtime overhead
> difference between the two ?[/color]

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(SomeInt eger)
Debug.Print SomeInteger & " <== this time, it changed"
AddFive SomeInteger
Debug.Print SomeInteger & " <== no parens, it changed again"
End Sub

Sub AddFive(NumberI n 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(Text 1)
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

Re: &quot;Call&quot ; function ?

On Thu, 3 Jul 2003 01:42:16 -0400, "Rick Rothstein"
<rickNOSPAMnews @NOSPAMcomcast. net> wrote:

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

[color=blue][color=green]
>> I have a function named
>>
>> Public Function getID3info(ByRe f x As String) As Integer
>>
>> What is the difference between
>>
>> getID3info (lvwDiscInfo.Se lectedItem)
>> and
>> Call getID3info(lvwD iscInfo.Selecte dItem) ?
>>
>> They both work properly - is there some kind of runtime overhead
>> difference between the two ?[/color]
>
>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.[/color]

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.[color=blue]
>
>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.
>[/color]
Ok - understood.
[color=blue]
>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(SomeInt eger)
> Debug.Print SomeInteger & " <== this time, it changed"
> AddFive SomeInteger
> Debug.Print SomeInteger & " <== no parens, it changed again"
>End Sub
>
>Sub AddFive(NumberI n 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.[/color]

I see. Interesting.[color=blue]
>
>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(Text 1)
>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.[/color]

Got it.
I went ahead and tested option 3:

Private Sub Command2_Click( )
DeleteText Text1
End Sub

and sure enough, it cleared the textbox.[color=blue]
>
>Hope the above helped.[/color]

Very much so - I'm glad I asked.[color=blue]
>
>Rick - MVP[/color]

Thanks
¤ Alias[color=blue]
>[/color]