Optional argument in subroutine not functioning according to MS

[VicM]

Folks,

I tried using an optional argument in a subroutine. When I try calling the subroutine from another subroutine and attempt to enter the second (optional) argument, the line of code turns red. When I try compiling I get a syntax error.
I'm attaching a Word .docx file showing the subroutine with the optional argument and what happens when I try to call it.

This is very confusing.

Any thoughts?

Vic

 

[Andrzejek]

Either:

Call SnglFilter("9", 1)

or

SnglFilter "9", 1

BTW - [tt]cmd9[/tt] is not very descriptive name for a command button....


---- Andy

There is a great need for a sarcasm font.

 

[VicM]

Thanks Andy I'll try those.
The button is the number 9
Vic

 

[strongm]

>The button is the number 9

heh!

 

[VicM]

Andy,

Thanks for the tip. That works.

But I still think it's confusing to split hairs like that. If you use the Call, you put the arguments in parens. Without the Call you don't use parens.

I don't think I ever knew that level of granularity. LOL

Thanks again,

Vic

 

[Andrzejek]

I always use [tt]Call MySub(parameter, another)[/tt] and never have a problem. Plus I know if I have a word [tt]Call[/tt] - I step into another piece of code.

>I still think it's confusing
Well, complain to Microsoft


---- Andy

There is a great need for a sarcasm font.

 

[strongm]

>confusing to split hairs like that

It's fairly explicit in the VBA documentation:

Remarks

You are not required to use the Call keyword when calling a procedure. However, if you use the Call keyword to call a procedure that requires arguments, argumentlist must be enclosed in parentheses. If you omit the Call keyword, you also must omit the parentheses around argumentlist.

 

[VicM]

Thanks strongm.

I hadn't actually seen that documentation.

There is still some confusion. When I didn't use the Call keyword, the line of code was SnglFilter ("9"). According to the documentation I shouldn't have the parens. However, this code compiled and did not produce a runtime error. So even though the documentation says to omit the parens when not using the Call keyword, apparently that doesn't apply when using only one argument. I only got the error when I included the second (optional) argument without the Call keyword.

 

[strongm]

>apparently that doesn't apply when using only one argument
That's not what is happening, as the parenthesis in this case is not functionally part of the procedure call (note the space between the procedure name and the opening bracket that the IDE will keep insisting on putting in if the expression within the parenthesis can be evaluated)

Consider the following, and see if you can see what is happening:

[blue]Public Sub test()
    Dim fred As Long
    
    fred = 0
    example fred
    MsgBox fred
    fred = 0
    example (fred)
    MsgBox fred
    
End Sub

Public Sub example(ByRef temp As Long)
    temp = 5
End Sub[/blue]

 

[VicM]

strongm

I'm trying to understand this.

Are you saying that if the argument in parens can be evaluated, that it's essentially being passed ByVal and not ByRef?
It's my understanding that if you don't include the ByRef keyword, it's assumed because it's the default.

Vic

 

[strongm]

>that it's essentially being passed ByVal and not ByRef?

No.

I'm trying to show that with

SomeName (x)

(x) is NOT an "argument in parens", it is a simply expression. The expression is evaluated before being passed as parameter (which was the point of my example). Essentially it is a shorthand for:

SomeName Evaluate(x)

effectively, it is handled as:

y = Evaluate(x)
SomeName y

which happily meets the rules

(Whether the expression is evaluable is checked at design time which is why you get an error if you try and add a second 'parameter')

 

[VicM]

strongm

Ok. I think I understand that now.

Thanks for you patience.

Vic