Application.ProcessMessagesコマンドはよく知られており、プログラムがコンピューターを拘束しないようにするために、長いプロセスで使用しています。
しかし、ビューをファイルにバッファリングする、かなり高速な一連の処理があります。バッファリング手順中に、いくつかのシステムメッセージが送信される場合があります（たとえば、再描画、スクロールバーの移動、またはその他のイベント）。バッファリングが完了するまで、これらがProcessMessagesによって処理されないようにします。
次のいずれかにする方法はありますか？
手順が完了するまでApplication.ProcessMessagesを禁止するか、
手順中に生成されたすべてのメッセージをトラップし、手順が終了するまでメッセージを解放しないでください。
不要ProcessMessagesなメッセージを送信しても続行できるようにすることは、問題があると分類されるべきではありません。コードを少しリファクタリングすることで、バッファリングメソッドを別のスレッドに移動してそこから移動できます。
コントロールの「ビジュアルコンテンツ」をファイルにコピーしようとしている場合は、
LockWindowUpdateそのコントロールへのすべてのペイントメッセージをオフにするWin32APIメソッド呼び出しを試してくださいWndProc必要に応じて、コントロールクラスまたは親クラスの/メソッドをオーバーライドし、DefaultWndProc送信されたメッセージごとに「true」を返すだけです。OnPaint」、「OnPaintBackground」など）をオーバーライドし、バッファリングが進行中の場合は何もしません。WndProcまたはをオーバーライドし、DefaultWndProc各メッセージに対して単にtrueを返すと、基本的に「オフ」になりますProcessMessages が、コントロールが正しく機能するために1つ以上のメッセージを処理する必要がある場合があるため、この方法で行うのは安全ではありません。
ProcessMessagesこれは、VCLフォームのメッセージループが構築された方法の一部であるため、（メッセージ処理用のVCLコードを書き直さずに）オフにすることはできません。
手順中に生成されたすべてのメッセージをトラップし、手順が終了するまでメッセージを解放しないでください。
あなたができる汚いハックがあります（あなたがより良い方法を思い付くことができない場合にのみ）：あなたはWin32フック
を使ってどんなメッセージでも見る（トラップする）ことができます。
具体的には、idHook値としてWH_CALLWNDPROCを指定してSetWindowsHookExを使用します。
その後、それらをリスト/キューに記録し、必要に応じて再送信できます。
私はWindows2に戻って、Windowsメッセージが予期しないときに発生することを学びました。ライブラリのどの部分でも、アプリのメッセージ処理が発生する可能性があります。流れを抑えるのではなく、状況に対してコードを堅牢にします。これは、BeginUpdate / EndUpdateペアを使用するのと同じくらい単純な場合もあれば、より複雑な場合もあります（一時的なものを使用し、最後に最終更新を実行します）。
衒学的レベルでは、Application.ProcessMessagesを「防止」する方法は、次のようなコードを呼び出さないことです。
数値計算とファイルI/Oのみを行うループを作成すると、メッセージが処理されていないため、ループを終了するまでUIがフリーズします。
不明な任意のコード（サードパーティライブラリ）の長時間実行操作中にUIを応答させたいが、その間にアプリで特定の種類のアクションを発生させたくない場合、それは別の問題です-それは防止することです再入可能。特定のアクティビティの進行中にコードの一部が使用されないようにする必要があります。たとえば、モーダルダイアログは、モーダルダイアログ自体を除くすべてのアプリのトップレベルウィンドウを無効にすることで、ダイアログの下にあるアプリウィンドウを操作できないようにします。