如果Instr函数与命名参数一起使用并且返回值分配给变量,则VBA编译错误 [英] VBA compile error if Instr function used with named parameter and return value assigned to variable

查看:219
本文介绍了如果Instr函数与命名参数一起使用并且返回值分配给变量,则VBA编译错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

背景:在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 '函数,编译器将返回"Expected:列表分隔符"错误:

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 ?

参考:VBA编辑器屏幕快照,其中包含" InstrRev "和" Instr "功能工具提示.差异以红色突出显示.

Reference : VBA editor screenshot for 'InstrRev' and 'Instr' functions tool tips. Differences are highlighted in red.

备注:' String1 '&根据上述屏幕快照工具提示的方括号," String2 "是" InStr "功能的可选参数.但是,它们是必需的,如下面的答案和Visual Basic语言参考中所述:

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) parse ,但不会,并且会产生与您看到的相同的错误.

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转移过来的包bag,而该语言(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.

奇怪的是,它的全限定名

Curiously its fully qualified name

 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编译错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆