讨厌的VBA命名行为

我使用访问2007年，这种行为可以复制如下。讨厌的VBA命名行为

1）创建新的访问数据库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控制之下。正因为如此，最近一整批无意义的“变化”已经被提交给知识库。

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

来源

2011-05-03 David

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

我周围具有源控制工作的方式是通过一个脚本，执行以下操作来运行我的仓库：

还原用VBA程序扩展名的所有修改过的文件（创建备份那些.orig文件）
做一个那些.orig的文件不区分大小写比较对口
如果没有改变（的情况下改变外）删除那些.orig的文件
对于剩下的那些.orig文件（那些无线个实际的变化）删除对应文件，并删除那些.orig扩展

这样做是有效地隐藏其中唯一的变化与VBA文件时要的情况下（恒定问题的文件，如您遇到）。它不会隐藏已对其进行其他修改的文件中的大小写更改。这远非完美的解决方案，但它是我所想到的最好的解决方案。

来源

2011-05-03 16:02:01 mwolfe02

我很高兴我不是唯一一个与vba作战的人！我可能会尝试你的脚本想法。但是现在我知道这个“特征”，我可能只是用它来生活，从现在开始，我一直使用帕斯卡案例命名我所有的变量。帕斯卡的情况是标准的vba库使用，所以这应该消除任何区分大小写的命名冲突。尽管令人讨厌的是，这违背了我对使用小写方法参数的偏好！ – David 2011-05-03 17:32:14

另外请记住，在VBA中，变量名不区分大小写。所以说明和描述在相同的范围内是相同的。

来源

2011-05-03 16:09:16 Bueller

讨厌的VBA命名行为

回答

相关问题