问题描述
背景:在 VBA 中,可以不带或带命名参数调用InStrRev"函数.
Background : In VBA, 'InStrRev' function can be called without or with named parameters.
'Call without named parameters
Call InStrRev("AB", "B") 'No compiler error
i = InStrRev("AB", "B") 'No compiler error
'Call with named parameters
Call InStrRev(StringCheck:="AB", StringMatch:="B") 'No compiler error
i = InStrRev(StringCheck:="AB", StringMatch:="B") 'No compiler error
关注:在 VBA 中,如果 'InStr' 函数,编译器会返回预期:列表分隔符"错误:
Concern : In VBA, the compiler returns "Expected: list separator" error if 'InStr' function :
- 使用命名参数调用和
它的返回值赋给一个变量
- Is called with named parameters and
Its return value is assigned to a variable
'Call without named parameters
Call InStr("AB", "B") 'No compiler error
i = InStr("AB", "B") 'No compiler error
'Call with named parameters
Call InStr(String1:="AB", String2:="B") 'No compiler error
i = InStr(String1:="AB", String2:="B") 'Compiler error : "Expected: list separator"
问题:当Instr"函数与命名参数一起使用并将其返回值分配给变量时,为什么会发生 VBA 编译器错误?是语言限制还是编译器错误?
Question : Why does VBA compiler error occur when 'Instr' function is used with named parameters and its return value is assigned to a variable ? Is it a limitation of the language or a compiler bug ?
参考:InstrRev"和Instr"函数工具提示的 VBA 编辑器屏幕截图.差异以红色突出显示.
Reference : VBA editor screenshot for 'InstrRev' and 'Instr' functions tool tips. Differences are highlighted in red.
备注:'String1' &'String2' 是 'InStr' 函数的可选参数,根据上面的截图工具提示方括号.但是,它们是必需的,如下面的答案和 Visual Basic 语言参考中所述:https://msdn.microsoft.com/EN-US/library/office/gg264811.aspx
Remark : 'String1' & 'String2' are optional arguments for 'InStr' function according to above screenshot tooltip square brackets. However, they are required, as mentioned in below answer and in Visual Basic language reference : https://msdn.microsoft.com/EN-US/library/office/gg264811.aspx
推荐答案
InStr
很奇怪,因为它的第一个参数 (Start
) 是可选的,但它的后续 String1
/String2
参数不是(尽管工具提示中有 []
) - 如果它们是可选的 InStr(1)
会解析,但它不会并产生与您看到的相同的错误.
InStr
is odd in that its first argument (Start
) is optional, but its subsequent String1
/String2
arguments are not (despite the []
in the tooltip) - If they were optional InStr(1)
would parse but it does not and generates the same error you see.
特别奇怪,因为 VBA 不允许这样做;那里的规则是非可选参数不能跟随可选参数,这是有道理的,因为有些情况下编译器无法将参数与函数预期的参数相匹配.这也强制它的所有参数都是变体.
Specifically its odd because VBA disallows this; the rule there is that non-optional arguments cannot follow optional arguments, which makes sense as there would be cases when the compiler could not match up the arguments to what the function expected. This also forces all of its arguments to be variants.
VB6/A 有很多来自 QBASIC 的包袱,并且该语言(iirc 不允许用户定义的可选参数)的 INSTR()
具有完全相同的签名,所以我假设您看到的行为是调用 InStr
时必须存在的特殊解析规则的产物.
VB6/A has a lot of baggage carried over from QBASIC, and that language (which iirc did not allow user defined optional arguments) has exactly the same signature for its INSTR()
so I assume the behaviour you see is an artifact of the special parsing rules that must exist for calls to InStr
.
奇怪的是它的全限定名
i = VBA.Strings.InStr(String1:="AB", String2:="B")`
会解析,但在运行时会产生错误,除非提供了 Start
:
does parse, but produces an error at runtime unless Start
is provided:
i = VBA.Strings.InStr(String1:="AB", String2:="B", Start:=1)`
按预期工作.
Call
表单可能看起来有效的一个原因是它没有操作并且可能会被优化掉.
One reason the Call
form may appear to work is thats its a no-op and may be optimised away.
VBA.X() 对比 X()
这完全没问题:
ptr = VBA.CLng(AddressOf someFunc)
这会生成解析时间预期表达式错误:
This generates a parse time Expected Expression error:
ptr = CLng(AddressOf someFunc)
这篇关于如果 Instr 函数与命名参数一起使用并且返回值分配给变量,则 VBA 编译错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!