討厭的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命名行爲

回答

相關問題