Just to clarify John Rudy's response.
The sytax is optional (small 'o'), meaning you don't have to use it. In my experience, most VB6 coders don't use the syntax and instead prefer regular 'unnamed' parameters.
If you do choose to use it, all subsequent paramters in the sub procedure call must be named.
The named paramter syntax can be used on all parameters, whether or not the corresponding argument was declared using the VBA keyword Optional
(capital 'O'). Consider, for example, this (slightly daft) VBA function with two parameters, one required and one Optional
:
Private Function TimesTen( _
ByVal Value As Long, _
Optional ByVal Factor As Long = 10 _
) As Long
TimesTen = Value * Factor
End Function
In VBA, I can call it using named parameters for the required parameter (the Optional
paramter can simply be omitted in VBA, unlike in C#.NET for which Type.Missing
must be used for all omitted Optional
parameters):
MsgBox TimesTen(Value:=9)
If I wanted to call it with the parameters in the 'wrong' order (why??) I can achieve this using named parameters:
MsgBox TimesTen(Factor:=11, Value:=9)
Trying to use a regular 'unnamed' parameter call after a named one causes a compile error:
MsgBox TimesTen(Value:=9, 11)
So why do VBA coders use named parameters if VB6 coders rarely do, even though they use essentially the same language? I think it is because the VBA generated by the MS Office applications' macro recorder tends to (always?) generate named parameters and many VBA coders learn programming this way.