WSH Script Error "Cannot use parentheses when calling a sub"

[ozmoeugene]

I have created a WSH script file, just for testing, which consist of the following code:

MapDrive ("R:","\\wfr-cwc6ygp3yf4\charles")

Sub MapDrive(sLetter, sUNC)
set oNet = WScript.CreateObject("WScript.NetWork")
oNet.MapNetworkDrive("R:", "\\wfr-cwc6ygp3yf4\charles")
End Sub

As you can see I call the mapDrive Sub routine. I keep getting the error "Cannot use parentheses when calling a sub".

Now I am not a programming novice, but I can't figure why I keep geting this error.

If anyone knows the reason I amd getting this error, please help!!!

Thanks ahead of time.

 

[dilettante]

The error is "telling you like it is."

In VBScript you don't use parens around the argument list when invoking a Sub.

If you really want to you can use [tt]Call MapDrive(...)[/tt] instead of just [tt]MapDrive ...[/tt].

Note that the documentation was written by C/C++/JavaScript types, and they made a lot of errors in their examples as well as providing some misleading syntax diagrams. It doesn't help that when there is only one argument/parameter using parens may appear to work fine:

[tt]OtherSub(arg1)[/tt]

In such a case those parens are really just redundant parens around an expression (which is merely [tt]arg1[/tt] here), not part of calling "OtherSub.

 

[tsuji]

Hello ozmoeugene,

This is how the documentation explain the construction.

To call a Sub procedure from another procedure, type the name of the procedure along with values for any required arguments, each separated by a comma. The Call statement is not required, but if you do use it, you must enclose any arguments in parentheses.

The following example shows two calls to the MyProc procedure. One uses the Call statement in the code; the other doesn't. Both do exactly the same thing.

Call MyProc(firstarg, secondarg)
MyProc firstarg, secondarg
Notice that the parentheses are omitted in the call when the Call statement isn't used.

In the way you use to call, the whole thing within the parantheses is taken as the first parameter and the second parameter is therefore considered as missing!

regards - tsuji

 

[dilettante]

I say that [tt]OtherSub(arg1)[/tt] appears to work because it may fail in some cases:

Option Explicit

Dim strQuery

Sub Hello(ByRef strQ)
  strQ = "Hello world"
End Sub

strQuery = "xxx"
Hello strQuery
MsgBox strQuery

strQuery = "xxx"
Hello(strQuery)
MsgBox strQuery

Here the first MsgBox dialog will say "Hello world" while the second will reply with "xxx" instead.

Why? Because the second call to Sub "Hello" is passing an evaluated expression to the Sub instead of a variable reference.

Kinky hmm? Amazing how many people make this mistake too, then spend hours debugging it.

 

[JohnYingling]

OtherSub(arg1) works because the parens surround a single parameter and denote that the argument is to be treated as an expression, whether or not it is.
So if it is a single argument, it is merely copied to a work variable and passed to the procvedure. A "side-effect" occurs when the caller expects to see any changes to a ByRef argument that has been enclosed in parens.

Dim I
Dim J
I = 1
Add1 I
' I is now 2
J = 1
Add1 (J)
' J is now 1
......
Sub Add1 ByRef arg
arr = arg + 1
End Sub

http://www.VBResizer.com

Forms/Controls Resizing/Tabbing

http://www.VBCompare.com

Compare Code

http://www.VBSortGen.com

Generate Sort Class in VB

http://www.Vbcompare.com/Check.Htm(1979

Check To MS)

 

[dilettante]

Yes, I should modify my original post's statement.

The extra parens are not merely redundant. They force expression evaluation, which is what my second post attempted to illustrate.