所以有一天我得到了一些奇怪的总和值,我完全被难倒了。我放弃了在VBA中使用sum函数并且只是添加了很长的值(通过循环),但后来我在某处读到使用VBA中的sum函数并不总是对开发人员可靠吗? (我再也找不到帖子,但我还在寻找它。)
这有什么道理吗?我知道很多人有不同的方法可以从一系列单元格中获得总和 - 而不是过于自以为是,其中一个会返回最准确的结果?
Sub testsums()
Dim metric1 As Integer, metric2 As Integer, metric3 As Integer
metric1 = Application.Sum(Range(("A1"), ("Z1")))
metric2 = Application.WorksheetFunction.Sum(Range(("A1"), ("Z1")))
metric3 = WorksheetFunction.Sum(Range(("A1"), ("Z1")))
End Sub
我正在努力重现我的错误 - 基本上当循环通过多行(15,000+)并获得总和时,有些人会在他们不应该的地方返回零。
答案 0 :(得分:5)
Application.Sum(Range(("A1"), ("Z1")))
这是针对Excel.Application
的后期电话,在运行时解决;与任何后期绑定调用一样(例如,针对Object
或Variant
),您没有获得IntelliSense,没有自动完成,也没有编译时验证,无论是名称中的拼写错误还是订单或参数数量。如果调用无效或函数导致错误,则返回 Error
值,您可以使用IsError
VBA函数进行验证(当然,如果有&# 39;函数名称中输入的错误是运行时错误#438"对象不支持此属性或方法")。
使这种语法有效的原因是Excel.Application
COM接口有一个标志使其可扩展 - 我不确定它是否已扩展为直接WorksheetFunction
界面,或者如果它只是让成员加倍,但无论如何,这是什么:你是否正在呼唤那些不会成员的成员。 t在编译时存在于Application
接口上。
Application.WorksheetFunction.Sum(Range(("A1"), ("Z1")))
这是对Excel.WorksheetFunction
的早期约束,在编译时解决;您将获得IntelliSense,自动完成和编译时验证。输入错误将无法编译,因为缺少必需的参数。如果调用无效或该函数导致错误,则引发 VBA运行时错误,您可以使用标准的VBA惯用错误处理使用On Error
语句处理该错误
WorksheetFunction.Sum(Range(("A1"), ("Z1")))
这与Application.WorksheetFunction.Sum
完全相同,只是它不完全合格。如果您的项目有WorksheetFunction
类,或者范围内有WorksheetFunction
个Application.WorksheetFunction
对象变量,那么就解决方案而言,它将优先于完全限定的RecyclerView
调用(这可能导致编译错误)。否则,相同。
哪一个更可靠"取决于你认为什么是可靠的"。我个人认为编译时分辨率完全值得,所以最可靠的#34;将是完全合格的早期版本。