【问题标题】:Annoying vba naming behaviour烦人的 vba 命名行为
【发布时间】:2011-08-17 20:29:09
【问题描述】:

我正在使用 access 2007,这种行为可以复制如下。

1) 创建新的 access 数据库 accdb 文件。
2) 打开数据库并创建新的 vba 模块。
3)创建第一个子程序sub1:

Sub sub1()
    Msgbox Err.Description
End Sub

4) 创建第二个子程序 sub2:

Sub sub2(Description as String)
    Msgbox Description
End Sub

此时一切正常。
5)但是如果我去更改 sub2 以便“描述”读取“描述”,即像这样将“D”更改为“d”:

Sub sub2(description as String)
    Msgbox description
End Sub

这也有连锁效应,也会改变 sub1 !所以 sub1 现在显示为:

Sub sub1()
    Msgbox Err.description
End Sub

为什么“Err.Description”变成了“Err.description”?

这种行为似乎对代码的实际功能没有影响,所以没有问题。我遇到的最大问题是我将我的 vba 模块导出为文本文件并将它们置于 SVN 控制之下。就在最近,大量无意义的“更改”因此提交到了存储库。

关于如何阻止这种情况发生的任何想法?

【问题讨论】:

    标签: ms-access vba ms-access-2007


    【解决方案1】:

    对不起。这是 VBA 的硬编码“功能”。在此处查看类似问题:How does one restore default case to a variable in VBA (Excel 2010)?

    我使用源代码控制解决这个问题的方法是通过执行以下操作的脚本运行我的存储库:

    1. 恢复所有带有 vba 代码扩展名的修改文件(创建备份 .orig 文件)
    2. 将 .orig 文件与其对应文件进行不区分大小写的比较
    3. 如果没有更改(大小写更改除外),请删除 .orig 文件
    4. 对于剩余的 .orig 文件(有实际更改的文件)删除对应文件并删除 .orig 扩展名

    这样做的目的是有效地隐藏文件,其中唯一的变化是案例(处理 VBA 文件时经常遇到的问题,正如您所遇到的那样)。它不会隐藏已对其进行了其他修改的文件中的大小写更改。这远不是一个完美的解决方案,但它是我想出的最好的解决方案。

    【讨论】:

    • 我很高兴我不是唯一一个与 vba 对抗的人!我可能会尝试您的脚本创意。但是现在我知道了这个“特性”,我可能只是忍受它,从现在开始,我在 vba 中的所有变量都始终使用 Pascal 大小写。 Pascal 大小写是标准 vba 库使用的,因此这应该消除任何区分大小写的命名冲突。虽然很烦人,但这违背了我对方法参数使用小写字母的偏好!
    【解决方案2】:

    另外请记住,在 VBA 中,变量名不区分大小写。所以Description和description在同一个范围内是一样的。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2012-08-26
      • 1970-01-01
      • 2013-09-09
      • 1970-01-01
      • 1970-01-01
      • 2010-12-13
      • 1970-01-01
      相关资源
      最近更新 更多