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。自那以后我没有任何问题。