これは私に何度も起こり、幽霊を追いかける多くの失われた時間をもたらしました。通常、非常に難しいタイミング関連のコードをデバッグしているときに、大量のOutputDebugString（）呼び出しを追加し始めるので、関連する操作のシーケンスをよく把握できます。問題は、Delphi6IDEはその状況を非常に長い間しか処理できないように見えることです。一般性を避けるために（可能な限り）、今行った具体的な例を使用します。
スレッド間セマフォロックコードとDirectShowタイムスタンプ計算コードのデバッグに数日を費やしました。これは非常に苛立たしい問題を引き起こしていました。考えられるすべてのバグを排除した後も、アプリケーションがオーディオを送信するSkypeに問題がありました。
約10秒後、通話の遠端であるテストに使用していた2台目のPCでSkypeから音声が聞こえるまでの遅延が大きくなり始めました。約20〜30秒で遅延が指数関数的に増加し始め、その時点でコードがトリガーされ、クリティカルセクションが長すぎて保持されていないかどうかを確認します。
幸いなことに、夜遅くはなく、以前にこれを経験したことがあるので、私は執拗にトレースを停止し、OutputDebugString（）の大部分をオフにすることにしました。ありがたいことに、それらのほとんどを条件付きコンパイラー定義でラップしていたので、簡単に実行できました。これを実行した瞬間に問題は解消され、コードは正常に機能していることがわかりました。
したがって、OutputDebugstring（）トラフィックの量があるしきい値を超えると、Delphi6IDEが実際に停止し始めているように見えます。おそらく、すべてのOutputDebugString（）レポートを保持するイベントログデバッガペインに文字列を追加するだけのタスクです。わかりませんが、TMemoまたは同様のコントロールに含まれる文字列が多すぎると、アプリケーションで同様の問題が発生します。
これを防ぐために、あなた方は何をしましたか？メソッド呼び出しを介してイベントログをクリアする方法、または少なくともそのサイズを制限する方法はありますか？また、この状況に対処するために、条件付き定義、IDEプラグインなどを介してどのような手法を使用していますか？