Excel VBA項目在編譯後崩潰

Question

我有一個大型的用戶窗體，當它被加載到內存時會引起一些問題。在Userform_Initialize事件中沒有任何異國情況發生（只需填充組合框並設置默認屬性）。 幾周前，當用戶表單不夠大（以KB爲單位）時，一切正常。最初，我認爲工作簿已損壞，並繼續導出每個用戶窗體，模塊和類，重新導入到新的工作簿中，然後按照以往的方式編譯項目。這並沒有解決這個問題。有趣的是，當我把一個Stop放在initialize事件的頂部，並且遍歷代碼時，一切正常。

重要思想

這讓我思考這個問題的可能原因是，用戶窗體是非常大的，因此正在採取比典型的更長的加載用戶窗體到內存中的進程加載。實質上，vb編輯器正在繼續執行初始化事件中的代碼，試圖訪問可能尚未存儲在內存中的控件。

我已經做了一些粗略的分析，以獲得一個相當好的想法，有多大的用戶表單是有問題的。用戶窗體被導出並重新導入到空白工作簿中。沒有用戶表單的工作簿大約在30 KB，用戶窗體的工作簿超過了350 KB，因此我們可以得出結論，用戶窗體大約在320 KB。

重要的是要指出，我在我的項目中有廣泛的錯誤處理，但是，我無法識別這個特定的錯誤，因爲它發生在初始化事件中（錯誤處理在這個特殊事件中是不可能的[Bovey，專業Excel開發，第489頁]）。

問題：具有時間延遲（例如，經由Windows API的Application.Wait或Sleep）之外，有另一種方法來避免崩潰？

UPDATE
事實證明，延遲申請沒有可靠的工作之一。我實際上刪除了整個Initialize事件也無濟於事。我在原帖中忘記提到的一件事是，我濫用了Debug -->> Compile VBA Project功能。請參閱下面的答案。

Answer 1

在處理完這段相當長的一段時間後，我的一個同事簡單地評論了一個隨機的代碼行（不在UserForm_Initialize中，只是在一些隨機模塊中），保存了文件並重新打開，沒有問題。然後我們發現問題不在代碼中，而是與Debug -->> Compile VBA Project。大多數情況下，我使用Debug -->> Compile VBA Project，大約每小時一次，因爲我正在編碼。然後我保存該文件並繼續在該編譯的文件上進行開發。說完之後，我可能會在兩週內運行約100次約Debug -->> Compile VBA Project。後來我發現，從芯片皮爾森此評論this website：

VBA代碼永遠不會存儲您在到 編輯器中鍵入純文本。立即將輸入轉換爲平臺和與版本無關的稱爲OpCodes的字節代碼。這些操作碼是 由編輯器轉換爲您在屏幕上看到的文本。編譯該項目時，編譯器將這些OpCode轉換爲 稱爲ExCodes的平臺和版本特定代碼。當您運行 代碼時，運行系統會根據ExCodes讀取ExCodes並代表項目執行實際機器代碼 。原則上類似於Java和Java虛擬機的工作，整個過程是 。

如果你要導出所有VBA代碼到文本文件，然後刪除 所有的模塊，然後重新導入從文本代碼文件重新 進入VBA（這正是羅布博維的代碼更加一樣），你會 看到文件大小的減少。這是因爲ExCodes被清除了 並且還沒有被重新創建。然後，如果編譯該項目，則 文件大小將增加，因爲現在它將ExCodes另外存儲到OpCodes中 。

你真的不需要編譯代碼。 VBA將在必要時自動執行 。但是，編譯命令也會執行語法 檢查，這是它唯一真正的實用目的。

這是羅布博維自己發現here（你還會發現在該網站羅布博維的代碼更加清晰）：

在創建VBA程序的過程中大量的垃圾代碼積聚你的文件。如果您不定期清理文件，您將開始遇到由此額外行李造成的奇怪問題。清理項目涉及將其所有VBComponents的內容導出爲文本文件，刪除組件，然後將組件從文本文件中導回。

然後我就像我在上面的原始問題那樣做了。我導出所有模塊，將它們重新導入到一個新的excel工作簿中，添加了相關的庫和DID NOT（像我之前那樣）運行Debug -->> Compile VBA Project。自那以後我沒有任何問題。