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的隐式过程/成员调用语法的工作方式有关.自显式隐式调用问世以来，大约四分之一个世纪以前，显式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
...并用括号括起来:
...and called with parentheses:
DoSomething (Application.ActiveCell) 'raises an error at runtime
这将引发对象必需"运行时错误#424.在其他情况下，可能还会发生其他错误:此处Application.ActiveCell范围对象引用正在按值进行评估并按值传递，而无论该过程的签名是否指定要传递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屋！
