VBA中括号效应的差异背后是什么? [英] What is behind this difference in parentheses effect in VBA?
问题描述
我没有在其他语言中看到过这个，但我在 VBA(我刚开始使用它)中看到了很多.假设您在 Word 中有一个表格并希望将行设置为特定高度.如果你这样做
I've not seen this in other languages but I see it a lot in VBA (which I just started working with). Suppose you have a table in Word and wish to set the rows to a certain height. If you do this
tbl.Rows.SetHeight InchesToPoints(1), wdRowHeightExactly
表格的行确实设置为 72 点或 1 英寸的高度.但是，如果您将参数括在括号中，这是我本能地做的事情，VBA 会给出错误 -- expected:=.
the table's rows indeed are set to 72 points or 1 inch in height. However, if you surround the arguments in parentheses, something I did instinctively, VBA gives an error -- expected:=.
我可以通过使用一次性变量来解决这个问题，就像这样
I can solve this by using a throw-away variable, like this
x = tbl.Rows.SetHeight (InchesToPoints(1), wdRowHeightExactly)
或者，当然，我不能简单地将参数括在括号中.
or, of course, I can simply not surround the arguments in parentheses.
Microsoft 的 有关 SetHeight 的文档方法 没有提到任何返回值，但无论如何，这种行为在整个 VBA 中都是广泛的.它不是特定于 SetHeight 方法的.
Microsoft's documentation on the SetHeight method doesn't mention any return value, but in any case, this behavior is extensive throughout VBA. It's not specific to the SetHeight method.
我的问题:这叫什么?我应该使用一次性变量还是丢弃括号?从微软的角度来看，逻辑是什么?使用其中一种是否有后果，我无法想象的后果(因为它们是未知的未知数)?
My questions: What is this called? Should I use a throw-away variable or throw away the parentheses? What's the logic from Microsoft's point of view? Are there consequences to using one or the other, consequences I can't imagine (because they are unknown unknowns)?
推荐答案
绝对不要引入丢弃变量"，特别是如果它未声明，尤其是如果您调用的是 Sub，一个不返回任何值的过程.那么你可以，如果你不介意编译时错误:
Definitely don't introduce a "throw-away variable", especially if it's not declared, and especially if what you're invoking is a Sub, a procedure that doesn't return any value. Well you can, if you don't mind a compile-time error:
预期的函数或变量.
现在...
这种行为在 VBA 中广泛存在.它不是特定于 SetHeight 方法的.
至于它叫什么，我猜正确的语法"是最合适的词.
这就是全部答案:它与 SetHeight 无关，而是与 VBA 的隐式过程/成员调用语法的工作方式有关.自从大约 25 年前隐式调用出现之后，显式 Call 语法就已经过时了.所以飞溅的 Call 关键字留下了 &没错，在您的代码中，确实会保留括号……如果您如此珍视它们.
That's the whole answer: it's not about SetHeight, it's about how VBA's implicit procedure/member call syntax works. The explicit Call syntax has been obsolete since the wonderful advent of implicit calls, about a quarter of a century ago. So splattering Call keywords left & right and all over your code will, indeed, keep you the parentheses... if you hold them so dear.
但隐式调用语法的逻辑"并没有那么复杂，真的.
But the "logic" of the implicit call syntax isn't all that complicated, really.
以下是我在 Documentation.SO 上写的关于 VBA 和括号的内容，希望对您有所帮助.
What follows is what I wrote on Documentation.SO about VBA and parentheses, hope it helps.
括号用于将函数调用的参数括起来.将它们用于过程调用可能会导致意外问题.
Parentheses are used to enclose the arguments of function calls. Using them for procedure calls can cause unexpected problems.
因为它们可以在运行时通过向过程传递可能意外的值以及在编译时通过简单的无效语法引入错误.
Because they can introduce bugs, both at run-time by passing a possibly unintended value to the procedure, and at compile-time by simply being invalid syntax.
冗余括号会引入错误.给定一个将对象引用作为参数的过程......
Redundant parentheses can introduce bugs. Given a procedure that takes an object reference as a parameter...
Sub DoSomething(ByRef target As Range)
End Sub
...并用括号调用:
DoSomething (Application.ActiveCell) 'raises an error at runtime
这将引发需要对象"运行时错误 #424.在其他情况下可能会出现其他错误:这里正在评估 Application.ActiveCell Range 对象引用并按值传递，而不管指定目标将被传递 ByRef 的过程签名.在上面的代码片段中，将 ByVal 传递给 DoSomething 的实际值是 Application.ActiveCell.Value.
This will raise an "Object Required" runtime error #424. Other errors are possible in other circumstances: here the Application.ActiveCell Range object reference is being evaluated and passed by value regardless of the procedure's signature specifying that target would be passed ByRef. The actual value passed ByVal to DoSomething in the above snippet, is Application.ActiveCell.Value.
括号强制 VBA 计算括号表达式的值，并将结果 ByVal 传递给被调用的过程.当评估结果的类型与过程的预期类型不匹配且无法隐式转换时，会引发运行时错误.
Parentheses force VBA to evaluate the value of the bracketed expression, and pass the result ByVal to the called procedure. When the type of the evaluated result mismatches the procedure's expected type and cannot be implicitly converted, a runtime error is raised.
此代码将无法编译:
MsgBox ("Invalid Code!", vbCritical)
因为表达式 ("Invalid Code!", vbCritical) 不能计算为一个值.
Because the expression ("Invalid Code!", vbCritical) cannot be evaluated to a value.
这将编译并工作:
MsgBox ("Invalid Code!"), (vbCritical)
但肯定会看起来很傻.避免多余的括号.
But would definitely look silly. Avoid redundant parentheses.
这篇关于VBA中括号效应的差异背后是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
