Home > Archive > Visual Basic > November 2005 > Calling a Function or a Procedure
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Calling a Function or a Procedure
|
|
| Abhishake 2005-11-26, 3:55 am |
| Dear All,
Please help me out in finding a the difference between two statement (1st
statement and 2nd Statement)in Visual basic 6.0 ,while calling any procedure
1st Statement :
call AnyProcedureName (Parameters 1,Parameter 2,Parameter 3)
2nd Statement :
AnyProcedureName (Parameters 1,Parameter 2,Parameter 3)
It would be appreciating if it is a deep disscussion.
Thanks
| |
| Larry Serflaten 2005-11-26, 3:55 am |
|
"Abhishake" <Abhishake@discussions.microsoft.com> wrote
>
> Please help me out in finding a the difference between two statement (1st
> statement and 2nd Statement)in Visual basic 6.0 ,while calling any procedure
>
> 1st Statement :
>
> call AnyProcedureName (Parameters 1,Parameter 2,Parameter 3)
>
> 2nd Statement :
> AnyProcedureName (Parameters 1,Parameter 2,Parameter 3)
>
> It would be appreciating if it is a deep disscussion.
There is no real mystery, if you use Call then you need to use parentheses
around the parameters, so the 1st statement would work (if the parameters
were valid parameters, and not the space containing phrases you show).
If you do not use Call then do not use parentheses, so that 2nd statement
would not compile. The only time you can use parentheses in a call to some
routine, without using the Call statement, is when you are returning a value
from a function:
X = SomeFunction(A, B, C)
LFS
| |
| Michael C 2005-11-26, 7:55 am |
| "Abhishake" <Abhishake@discussions.microsoft.com> wrote in message
news:8680C048-63AD-4AD5-AD81-AC5C4BB6F7B7@microsoft.com...
> Dear All,
>
> Please help me out in finding a the difference between two statement (1st
> statement and 2nd Statement)in Visual basic 6.0 ,while calling any
> procedure
>
> 1st Statement :
>
> call AnyProcedureName (Parameters 1,Parameter 2,Parameter 3)
>
> 2nd Statement :
> AnyProcedureName (Parameters 1,Parameter 2,Parameter 3)
>
> It would be appreciating if it is a deep disscussion.
It's hardly likely to be a deep discussion, it's just 2 different ways to
write the same thing with no difference once compiled (I'm assuming the
second statement is either assigned to a value or the parentheses are
removed).
Michael
| |
| Bob Butler 2005-11-26, 6:55 pm |
| "Abhishake" <Abhishake@discussions.microsoft.com> wrote in message
news:8680C048-63AD-4AD5-AD81-AC5C4BB6F7B7@microsoft.com
> Dear All,
>
> Please help me out in finding a the difference between two statement
> (1st statement and 2nd Statement)in Visual basic 6.0 ,while calling
> any procedure
>
> 1st Statement :
>
> call AnyProcedureName (Parameters 1,Parameter 2,Parameter 3)
>
> 2nd Statement :
> AnyProcedureName (Parameters 1,Parameter 2,Parameter 3)
>
> It would be appreciating if it is a deep disscussion.
Your second statement as written is not valid VB syntax but, in general,
there are two ways to call "Sub" procedures in VB:
CALL procedurename(argumentlist)
and
procedurename argumentlist
For "Function" procedures you can use the same methods as above and also use
returnvalue=procedurename(argumentlist)
and
If procedurename(argumentlist) Then
and otherwise use the "procedurename(argumentlist)" format in expressions
Which format to use for Sub procedures is a matter of style. There is no
difference when the "correct" syntax is used.
The problem comes in when you mix the two formats by omitting CALL and
trying to use the () characters anyway (this only works for procedures with
0 or 1 parameters; 2+ parameters results in a syntax error). When you code
something like
MySub (x)
VB sees that no CALL is used and assumes you are using the statement format
and interprets it as
CALL MySub((x))
To pass the value VB evaluates the expression "(x)" and passes the result.
If the parameter is ByVal then there is no effective difference. If the
parameter is ByRef then any changes made to the value in MySub are lost
because VB can't update the value of the expression (x) any more than it
could if you had used "MySub x+1" or any other expression. This can be
useful if you understand it and a great way to introduce a bug into your app
if yout don't.
The syntax error with multiple arguments comes up because if you try to use
MySub (x,y)
VB reads it as if you had entered
Call MySub((x,y))
but "(x,y)" is not a valid expression.
--
Reply to the group so all can participate
VB.Net: "Fool me once..."
| |
|
|
"Bob Butler" <tiredofit@nospam.com> wrote in message
news:exO0vUp8FHA.2192@TK2MSFTNGP14.phx.gbl...
> "Abhishake" <Abhishake@discussions.microsoft.com> wrote in message
> news:8680C048-63AD-4AD5-AD81-AC5C4BB6F7B7@microsoft.com
>
> Your second statement as written is not valid VB syntax but, in general,
> there are two ways to call "Sub" procedures in VB:
> CALL procedurename(argumentlist)
> and
> procedurename argumentlist
>
> For "Function" procedures you can use the same methods as above and also
use
> returnvalue=procedurename(argumentlist)
> and
> If procedurename(argumentlist) Then
> and otherwise use the "procedurename(argumentlist)" format in expressions
>
> Which format to use for Sub procedures is a matter of style. There is no
> difference when the "correct" syntax is used.
>
> The problem comes in when you mix the two formats by omitting CALL and
> trying to use the () characters anyway (this only works for procedures
with
> 0 or 1 parameters; 2+ parameters results in a syntax error). When you
code
> something like
> MySub (x)
> VB sees that no CALL is used and assumes you are using the statement
format
> and interprets it as
> CALL MySub((x))
> To pass the value VB evaluates the expression "(x)" and passes the result.
> If the parameter is ByVal then there is no effective difference. If the
> parameter is ByRef then any changes made to the value in MySub are lost
> because VB can't update the value of the expression (x) any more than it
> could if you had used "MySub x+1" or any other expression. This can be
> useful if you understand it and a great way to introduce a bug into your
app
> if yout don't.
>
> The syntax error with multiple arguments comes up because if you try to
use
> MySub (x,y)
> VB reads it as if you had entered
> Call MySub((x,y))
> but "(x,y)" is not a valid expression.
>
> --
> Reply to the group so all can participate
> VB.Net: "Fool me once..."
>
Some additional 'deepening'. <g>
The <argumentlist> for any procedure can include the keywords ByVal and
ByRef to redefine how the arguments are to be used by the called procedure.
However, you can only use these keywords with a Call statement if the
procedure has been declared with the "Declare Function".
For reasons Bob noted above, you should always use the Call Statement inside
WriteProperties event to avoid possible erronous evaluations.
You can use the Call Statement on Functions as well, in which case the
return is discarded. There once was a common belief that this in some way
saved some clicks and improved performance. Likely more myth than fact with
a compiled app.
"Officially" the Pros and Microsoft always recommend using the Call
Statement to add 'Readiblity' to your code. But because of the occasional
'Gotcha' that Bob pointed out - most programmers avoid it like the plague.
<g>
-ralph
| |
| Bob Butler 2005-11-26, 6:55 pm |
| "Ralph" <nt_consulting64@yahoo.com> wrote in message
news:4tSdndUVdLReBxXenZ2dnUVZ_vidnZ2d@ar
kansas.net
> For reasons Bob noted above, you should always use the Call Statement
> inside WriteProperties event to avoid possible erronous evaluations.
Huh?
> You can use the Call Statement on Functions as well, in which case the
> return is discarded. There once was a common belief that this in some
> way saved some clicks and improved performance. Likely more myth than
> fact with a compiled app.
IIRC there was one release (back in the VB3 days) where not using CALL
resulted in a memory leak but that was fixed. That could be me
mis-remembering something else but either way it's irrelevent now.
> "Officially" the Pros and Microsoft always recommend using the Call
> Statement to add 'Readiblity' to your code. But because of the
> occasional 'Gotcha' that Bob pointed out - most programmers avoid it
> like the plague. <g>
Huh? What 'gotcha' did I point out that would make people avoid it? If
anything the 'gotcha's associated with CALL lead to always using it, not
avoiding it.
--
Reply to the group so all can participate
VB.Net: "Fool me once..."
| |
|
|
"Bob Butler" <tiredofit@nospam.com> wrote in message
news:OaqQUBr8FHA.1188@TK2MSFTNGP12.phx.gbl...
> "Ralph" <nt_consulting64@yahoo.com> wrote in message
> news:4tSdndUVdLReBxXenZ2dnUVZ_vidnZ2d@ar
kansas.net
>
> Huh?
>
>
> IIRC there was one release (back in the VB3 days) where not using CALL
> resulted in a memory leak but that was fixed. That could be me
> mis-remembering something else but either way it's irrelevent now.
>
>
> Huh? What 'gotcha' did I point out that would make people avoid it? If
> anything the 'gotcha's associated with CALL lead to always using it, not
> avoiding it.
>
> --
> Reply to the group so all can participate
> VB.Net: "Fool me once..."
>
I vaguely remember that bug too, now that you mentioned it.
As for the latter, I was refering to the fact that during rapid prototyping
procedures are often loosely defined as subs or functions. After about 3 or
5 challenges from the runtime - newbies soon abandon using Call.
I didn't mean that one SHOULD avoid using it, only that as one of the better
pieces of advice that one gets, it is one that is often universally ignored.
-ralph
| |
| Bob Butler 2005-11-26, 6:55 pm |
| "Ralph" <nt_consulting64@yahoo.com> wrote in message
news:XrSdnRvcaofEPxXenZ2dnUVZ_vudnZ2d@ar
kansas.net
>
> As for the latter, I was refering to the fact that during rapid
> prototyping procedures are often loosely defined as subs or
> functions. After about 3 or 5 challenges from the runtime - newbies
> soon abandon using Call.
Hmmm... maybe I'm just not awake yet but I rarely, if ever, find that I need
to change a Sub to a Function or vice-versa and I'm still not understanding
what challenges you'd be getting from the runtime that would make you
abandon using Call. We should probably just leave this as a non-meeting of
the minds.
--
Reply to the group so all can participate
VB.Net: "Fool me once..."
| |
|
|
"Bob Butler" <tiredofit@nospam.com> wrote in message
news:e9UNBUs8FHA.2036@TK2MSFTNGP14.phx.gbl...
> "Ralph" <nt_consulting64@yahoo.com> wrote in message
> news:XrSdnRvcaofEPxXenZ2dnUVZ_vudnZ2d@ar
kansas.net
>
> Hmmm... maybe I'm just not awake yet but I rarely, if ever, find that I
need
> to change a Sub to a Function or vice-versa and I'm still not
understanding
> what challenges you'd be getting from the runtime that would make you
> abandon using Call. We should probably just leave this as a non-meeting
of
> the minds.
>
> --
> Reply to the group so all can participate
> VB.Net: "Fool me once..."
>
Agreed.
You're too grizzled and experienced. You would have to work with a lot of
newbies, to appreciate the view. <g>
We both agree that common use of the Call Statement should be viewed as a
'Best Practice", correct?
-ralph
-ralph
| |
| Bob Butler 2005-11-26, 6:55 pm |
| "Ralph" <nt_consulting64@yahoo.com> wrote in message
news:FvKdnVIgs8PlWBXeRVn-og@arkansas.net
> You're too grizzled
LOL, how did you know that I haven't shaved for the last 10 days!
> and experienced. You would have to work with a
> lot of newbies, to appreciate the view. <g>
>
> We both agree that common use of the Call Statement should be viewed
> as a 'Best Practice", correct?
Actually.... no. Any list of Best Practices for VB that I have wouldn't
take a stand either way; the only thing I insist on is not using () around
the argument if you aren't using CALL. Other than that it's purely a matter
of style and I sometimes use CALL and sometimes omit it. Sometimes it just
"feels" like it should be there for clarity. Sometimes you feel like a nut.
Sometimes you don't. <g>
--
Reply to the group so all can participate
VB.Net: "Fool me once..."
| |
| Michael C 2005-11-26, 6:55 pm |
| "Ralph" <nt_consulting64@yahoo.com> wrote in message
news:FvKdnVIgs8PlWBXeRVn-og@arkansas.net...
> Agreed.
>
> You're too grizzled and experienced. You would have to work with a lot of
> newbies, to appreciate the view. <g>
>
> We both agree that common use of the Call Statement should be viewed as a
> 'Best Practice", correct?
I think it should never be used. The whole idea of writing a function or sub
is to make it look like a command that would sit along side built in
commands. eg Redim MyArray(10) vs ResizeArray MyArray, 10 the second should
not be distinguished with a call statement.
Michael
| |
| Jeff Johnson [MVP: VB] 2005-11-28, 6:55 pm |
|
"Ralph" <nt_consulting64@yahoo.com> wrote in message
news:FvKdnVIgs8PlWBXeRVn-og@arkansas.net...
> We both agree that common use of the Call Statement should be viewed as a
> 'Best Practice", correct?
INFIDEL!!
Call. Blech. Might as well bring back Let for variable declarations.
Look, now you went and got me started....
| |
| Larry Serflaten 2005-11-28, 6:56 pm |
|
"Jeff Johnson [MVP: VB]" <i.get@enough.spam> wrote
>
>
>
> Call. Blech. Might as well bring back Let for variable declarations.
If only on the declarations, it wouldn't be so bad, but Let was actually
used for each and every variable assignment!
I think Call would have served us all better had it been implemented like
the Call command in a batch file. There it is used to launch a second
batch file and can act on the returned error code. VB lacked that return
value, which would often have been nice to have....
LFS
| |
| Jeff Johnson [MVP: VB] 2005-11-28, 6:56 pm |
|
"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:%23CLC9mF9FHA.3372@TK2MSFTNGP10.phx.gbl...
>
> If only on the declarations, it wouldn't be so bad, but Let was actually
> used for each and every variable assignment!
Urf. I meant assignment, not declaration. I blame the 4-day w end.
|
|
|
|
|