5

我看到一些 SO 用户在尝试使用 ; 的某些变体时遇到了问题Cells.Count。VBA 代码在某些情况下会引发溢出错误。

作为参考，请参阅对此答案的评论：

我认为这会起作用，但我得到一个“溢出”错误，它指向代码“If Master.Cells.SpecialCells(xlCellTypeVisible).Count > 0 Then”——它似乎没有过滤任何特别的东西– 用户 1556069

这个答案：

这是 onyl 工作（和 Cells.Count 没有工作），因为后者使用了一个整数，16 位，最大值 65,536 并且整个电子表格返回了一个更大的数字？– 快速代码

我假设在幕后某处 VBA 试图将单元格计数强制为小整数（16 位）或长整数（32 位）。Excel 2007 工作表的单元格计数会溢出这两种数据类型。不幸的是，我现在无法隔离它，因为我手边没有 Excel 2007 的副本，并且实际上无法重现您的错误。– mwolfe02

为了理解这一点，我尝试复制自己并在尝试分配Cells.Count为整数时出现溢出。这是有道理的，因为该值对于 Integer 数据类型来说太大了。

在 Excel 2003 和 2010 中使用下面的代码，当我尝试分配为 Long 或 Variant 时，我得到了一个数字结果。

Option Explicit

Sub testInteger()
    Dim i As Integer
    i = Cells.Count 'Overflow
    Debug.Print i 'Doesn't get this far...
End Sub

Sub testLong()
    Dim l As Long
    l = Cells.Count
    Debug.Print l 'Prints 16777216 in both versions
End Sub

Sub testVariant()
    Dim v As Variant
    v = Cells.Count
    Debug.Print v 'Prints 16777216 in both versions
End Sub

正如您在我的评论中看到的那样，该Cells.Count值是16777216（对于 2003 年是正确的），但对于两个版本都是相同的，这对我来说没有意义。从上述链接的答案之一中引用mwolfe02 ：

Excel 2007 工作表有 1,048,576 行和 16,384 列，总共 17,179,869,184 个单元格。

这告诉我 2010 年印刷的价值至少应该是（我相信它应该真的是一样的）17,179,869,184。

那么为什么这个数字不能正确打印/为什么在 2010 年返回 2003 的值？

4

1 回答 1

7

在计算如此大的数字时，请使用.Countlarge属性。

例如

Sub CellsCount()
    Dim l As Double
    l = ActiveSheet.Cells.CountLarge
    Debug.Print l
End Sub

也永远不要使用Cells.Count或Cells.CountLarge不指定工作表对象。这是为了确保我们不会在兼容模式下得到不正确的计数/错误。同样永远不要使用Rows.Count. 始终使用ws.Rows.Count. 这是人们在尝试查找 excel 中的最后一行时最常犯的错误。例如

这

lRow = ws.Range("A" & Rows.Count).End(xlUp).Row

和

lRow = ws.Range("A" & ws.Rows.Count).End(xlUp).Row

可能不会总是给你相同的结果。

我还建议进一步阅读此内容。

于 2012-07-30T23:54:28.980 回答