这种情况不止一次发生在我身上,导致我在追逐鬼魂时浪费了很多时间。通常,当我调试一些非常困难的与时序相关的代码时,我开始添加大量的 OutputDebugString() 调用,这样我就可以很好地了解相关操作的顺序。问题是,Delphi 6 IDE 似乎只能长时间处理这种情况。我将使用一个我刚刚经历过的具体示例来避免笼统(尽可能)。
我花了几天时间调试我的线程间信号量锁定代码以及我的 DirectShow 时间戳计算代码,这导致了一些令人沮丧的问题。在消除了我能想到的所有错误之后,我的应用程序向其发送音频的Skype仍然存在问题。
大约 10 秒后,我在用于测试的第二台 PC(通话的远端)上从 Skype 发出我的说话和听到我的声音之间的延迟开始增加。在大约 20 到 30 秒时,延迟开始呈指数增长,此时触发代码我有检查关键部分是否被持有太久。
幸运的是,现在还不算太晚,并且之前经历过这种情况,我决定停止无情地跟踪并关闭大部分 OutputDebugString()。值得庆幸的是,我将它们中的大多数包装在条件编译器定义中,因此很容易做到。我这样做的那一刻,问题就消失了,结果证明我的代码运行良好。
因此,当 OutputDebugstring() 流量超过某个阈值时,Delphi 6 IDE 似乎开始真正陷入困境。也许这只是将字符串添加到包含所有 OutputDebugString() 报告的 Event Log 调试器窗格的任务。我不知道,但是当 TMemo 或类似控件开始包含太多字符串时,我在我的应用程序中看到了类似的问题。
你们这些人做了什么来防止这种情况发生?有没有一种方法可以通过某种方法调用或至少一种限制其大小的方法来清除事件日志?另外,您通过条件定义、IDE 插件或其他方式使用什么技术来应对这种情况?