Excel VBA项目编译后崩溃

Question

我在一个项目中有一个很大的用户窗体，当它被加载到内存中时会导致一些问题。 Userform_Initialize 事件中没有发生任何奇怪的事情（只是填充组合框并设置默认属性）。 几周前，当用户表单没有那么大（以 KB 为单位）时，一切都运行良好。最初，我认为工作簿已损坏并继续导出每个用户窗体、模块和类，重新导入到新工作簿中，然后像往常一样编译项目。这并没有解决问题。有趣的是，当我将 Stop 放在初始化事件的顶部并逐步执行代码时，一切正常。

主要思想

这让我想到问题的可能原因是用户表单非常大，因此将用户表单加载到内存中的过程比典型的加载时间要长。本质上，vb 编辑器继续执行初始化事件中的代码，尝试访问可能尚未在内存中的控件。

我做了一些粗略的分析，以便很好地了解所讨论的用户表单有多大。用户表单已导出并重新导入空白工作簿。没有用户窗体的工作簿在30 KB 附近，而有用户窗体的工作簿在350 KB 附近，因此我们可以得出用户窗体在320 KB 附近的结论。

请务必注意，我的项目中有大量错误处理，但是，我无法识别此特定错误，因为它发生在初始化事件中（在此特定事件中无法进行错误处理 [Bovey，Professional Excel 开发，第 489 页]）。

问题：除了时间延迟（例如 Application.Wait 或 Sleep 通过 Windows API），还有其他方法可以避免崩溃吗？

更新
事实证明，延迟应用程序也不能可靠地工作。我实际上也删除了整个 Initialize 事件也无济于事。我在原始帖子中忘记提及的一件事是我滥用了Debug -->> Compile VBA Project 功能。请参阅下面的答案。

Answer 1

在处理了很长一段时间后，我的一位同事简单地注释了一行代码（不在UserForm_Initialize 中，只是在某个随机模块中），保存了文件，然后毫无问题地重新打开它。然后我们发现问题不在于代码，而在于Debug -->> Compile VBA Project。大多数情况下，我在编码时使用Debug -->> Compile VBA Project，大约每小时一次。然后我保存该文件并继续在同一个编译文件上进行开发。当一切都说完了，我可能会在两周的时间里运行Debug -->> Compile VBA Project 大约 100 次。然后我在this website 上找到了来自 Chip Pearson 的评论：

VBA 代码永远不会存储为您在 编辑。输入立即转换为平台和 与版本无关的字节码称为 OpCodes。这些操作码是 由编辑器转换为您在屏幕上看到的文本。当你 编译项目，编译器将这些 OpCodes 转换为 特定于平台和版本的代码称为 ExCodes。当你运行 代码，运行时读取 ExCodes 并执行实际的机器代码 代表基于 ExCodes 的项目。这整个过程是 原理上类似于 Java 和 Java 虚拟机的工作方式。

如果您要将所有 VBA 代码导出到文本文件，然后删除 所有模块，然后从文本文件中重新导入代码 进入 VBA（这正是 Rob Bovey 的 Code Cleaner 所做的），您将 看到文件大小减小。这是因为 ExCode 已被清除 并且尚未重新创建。然后，如果你编译项目， 文件大小会增加，因为现在它还存储 ExCodes 到操作码。

您真的不需要编译代码。 VBA会自动做 必要时。但是，编译命令也有语法 检查，这是它唯一真正的实际用途。

这是来自 Rob Bovey 自己找到的 here（您还可以在该网站上找到 Rob Bovey 的 Code Cleaner）：

在创建 VBA 程序的过程中，您的文件中会积聚大量垃圾代码。如果您不定期清理您的文件，您将开始遇到由这些额外包袱引起的奇怪问题。清理项目涉及将其所有 VBComponents 的内容导出到文本文件，删除组件，然后从文本文件中重新导入组件。

然后我就像我在原始问题中所做的那样做了。我导出了所有模块，将它们重新导入到一个新的 Excel 工作簿中，添加了相关库，并且没有（像以前一样）运行 Debug -->> Compile VBA Project。从那以后我没有遇到任何问题。