Smart questions
Smart answers
Smart people
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Member Login




Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

tg2003 (IS/IT--Management) (OP)
6 Jun 08 4:03
Hi,

I'm trying to understand what is that real meaning: When I call to a subroutine/function with "call" - Is it forked and run in concurrent mode, like a thread? Or the called sub/function is ran and when it stops it returns back to the main function?

I've read the MSDN help, but got no answers about it.

I'm asking it since I have a subroutine that if I call it with "call" - it doesn't works well, but if I omit the "call" - it works well.

Thanks in advance!
Helpful Member!  strongm (MIS)
6 Jun 08 4:48
VB is single-threaded.

But threading isn't your issue. I'd guess that the real issue is the Call keyword. Have a look at the followingways of running a procedure, and see if it helps illutrate what is going on:

CODE

Option Explicit

Private Sub Command1_Click()
    myRoutine Text1
    myRoutine (Text1)
    Call myRoutine(Text1)
End Sub


Public Sub myRoutine(strTextControl As Variant)
    MsgBox TypeName(strTextControl)
End Sub
vladk (Programmer)
6 Jun 08 8:26
strongm,

I just read this thing in Help:

If you omit the Call keyword, you also must omit the parentheses around argumentlist.

In your example you use the parentheses. Is it some undocumented feature? With more than one argument it is impossible, with one - possible, and it looks like it is treated differently. What is it? It looks like VB digests the parentheses - treats the whole thing like expression. But what will be the rule? What to expect?

Thank you!

vladk
JoeAtWork (Programmer)
6 Jun 08 10:00
As far as I know there is no difference in behaviour whether you use the Call statement or not.  I would say that it is rarely used by the majority of VB programmers (just more code to type, so why bother).

Quote (tg2003):

Or the called sub/function is ran and when it stops it returns back to the main function?
When a sub/function ends then control always returns to the calling procedure.

You have not stated in what way your subroutine "doesn't work well" - so there is no way for us to diagnose.  Posting your code and the error you get would help.

strongm (MIS)
6 Jun 08 12:18
>there is no difference in behaviour whether you use the Call statement or not

There is a difference in the way expressions in parenthesis are interpreted. And my suspicion is that this is the route cause of the OPs problem

>In your example you use the parentheses. Is it some undocumented feature?

No, it isn't undocumented. Unless instructed otherwise (e.g. by the presence of the Call keyword), VB will try to evaluate an expression inside parenthesis; i.e. it is not an argument list (you may be more familiar with this use of parenthesis in more complex expressions when trying to control the order of evaluation)
JoeAtWork (Programmer)
6 Jun 08 14:19
StrongM - I tried your code and see what you mean.  Of course, that is only a problem if the parameter is a Variant.

I'm sure the problem could be cleared up quickly if the OP posted his code.

dilettante (MIS)
7 Jun 08 11:00
The problems occur constantly when people are clueless.  The real head scratcher for some seems to be:

SubName (Param1, Param2)

... which won't compile.
xwb (Programmer)
7 Jun 08 15:24
The parentheses implies a ByVal parameter.  Most of the parameters are byval anyway but sometimes the compiler doesn't know what to do so you have to help it by putting in parentheses.

The clueless example, well, I suffer from it too.  I normally stick in a call instead of removing the parentheses.  Takes 1 second to type "call " but quite a few more to remove the parentheses.
strongm (MIS)
7 Jun 08 17:58
Sorry, but that's just ... wrong. Completely and utterly wrong. The parenthesis have nothing whatsoever to do with implying a ByVal parameter.


  
xwb (Programmer)
8 Jun 08 2:17
dilettante (MIS)
8 Jun 08 2:43
Wrong again.  Same rules in VBScript.
MajP (TechnicalUser)
9 Jun 08 9:25
The combination of parenthese and call determine if the functions return value is discarded:

From help file

Quote:


You are not required to use the Call keyword when calling a procedure.
1)However, if you use the Call keyword to call a procedure that requires arguments, argumentlist must be enclosed in parentheses.
2)If you omit the Call keyword, you also must omit the parentheses around argumentlist.
3)If you use either Call syntax to call any intrinsic or user-defined function, the function's return value is discarded.

That is why
X = msgbox("Do you want..",vbyesno)
returns a value
but
msgbox "Do you want..."

And (rule 1)
call mySubroutine(x,y)
or (rule 2)
mySubrounte x,y
 
xwb (Programmer)
9 Jun 08 18:41

Quote (dilettante):


Wrong again.  Same rules in VBScript.
See http://support.microsoft.com/default.aspx?scid=kb;EN-US;244012
dilettante (MIS)
9 Jun 08 19:39
Yes, there is that hack for calling an existing component's method.  But in writing VBScript you declare ByVal parameters just as in VB6.  Forcing expression evaluation by using parentheses does not "imply a ByVal parameter" at all.  It simply coerces the parameter to a value having the proper type.

It may be necessary in places like that shown at the linked article but it isn't a substitute for declaring procedures properly in VBScript... or whatever language is being used.  Normally if a parameter is declared ByRef it's for a reason: returning a value.

Defaulting to ByRef is unfortunate in a way, but defaulting to the most general case lets beginners get programs working easily.  It isn't the best way to write programs though (see The "Works on My Machine" Certification Program).
strongm (MIS)
9 Jun 08 20:13
I'm afraid that you are not understanding the article correctly. Which isn't all that surprising because the article is slightly misleading

In summary all it really says is that the parenthesis force the evaluation of the expression (exactly as they do in VB, and as we pointed out earlier in the thread).

This returns a new pointer to a new memory location containing the result of the evaluation. It is this new pointer that then gets passed to the sub, function (or COM object). One consequence of it being a new pointer is that it behaves like a ByVal parameter, in that making a change to the data pointed at by the new pointer clearly cannot change the data pointed at by the old pointer.

In other words, you have not actually changed the behaviour of VBS to support ByVal - you are still passing ByRef, it is just that you are passing a different variable ...

 
xwb (Programmer)
10 Jun 08 7:17
Thanks for the clarification

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close