UIスレッドがWaitHandleまたは他のスレッドプリミティブで待機中にすべてのWindowsメッセージを処理する方法はありますか？WaitHandleを待っている間にメッセージループを実行します
私はそれが非常に乱雑な再入可能問題を引き起こす可能性があることを認識しています。とにかくやりたい
EDIT：UIスレッドで実行する必要がある複雑な関数の途中で待機が発生します。したがって、待機をバックグラウンドスレッドに移動することはオプションではありません。
別のバックグラウンドスレッドで「複雑な機能を分割できません」という全体を実行し、必要なときにのみGUIに報告するようにしました（Invoke/BeginInvokeメソッドを使用）コントロール上）。
さらに強化されたバージョンでは、UIに依存しない非UIコントローラで複雑な関数を実行し、単体テストが容易になります。 UIにコールバックし、UIに結果を表示するには、コントローラが使用可能なイベントにUIを従属させることによって簡単に到達できます。
なぜ、待っているスレッドを生成して、適切な接続点でメッセージ（または何でも）を介してUIスレッドに通知させてもらうのはなぜですか？
これは、ブロッキングイベント中のUIスレッドメッセージ処理を可能にする通常の方法です。
編集： 私は今見ています - あなたは、そのアプリケーションのロジックをUIコードに組み込んでいます。さて、これは本当にデザイン上の問題です。長期的には、UIから独立したオブジェクトへのその機能を壊し、作業者のUIとステータスをやりとりするためのメカニズムを使用する方がよいでしょう。
UIコードをUIに集中させる利点の他に、ロジックコードを個別にユニットテストすることができます。
C＃についてはわかりませんが、プレーンなWin32プログラミングでは、実際に待機するためにMsgWaitFor ...（）関数の1つを使用できます。待機中のオブジェクトが通知されたときだけでなく、メッセージがメッセージキューに存在するときに通知します。メッセージが存在すると報告する場合は、GetMessage（）、TranslateMessage（）、およびDispatchMessage（）を呼び出してメッセージを処理し、次に待機状態に戻ることができます。
CoWaitForMultipleHandlesも使用できます。そのための.NET APIがあるかどうかは不明です。 – FuleSnabel
通常、待機条件を別のスレッドに設定することをおすすめします。
しかし、あなたはいつでもメッセージ・ポンプを処理するためにいつでも呼び出すことができます。待機ハンドル（「タイムアウト」、「イベントの実行」、「タイムアウトの待機」など） 「the waithandle」を通して）。
+1、UIスレッドでの待機はクールではありません。コールバックを使用します。 –
UIスレッド（UIにバインドされたスレッドセーフではないデータオブジェクト）で実行する必要がある関数の途中で待機しているため、ローカル変数を分割して保存する必要はありません。 – SLaks
UIロジックではなく、UIスレッドからのみ読み取ることができるデータオブジェクトです。 – SLaks