私のアプリケーションは、非常に大きなデータの複雑な処理を行うためにスレッドに大きく依存しています。処理が行われている間、UIを更新する必要があります。私はUIを更新するための方法を知っており、使用しようとしましBackgroundWorker's OnProgressChangedた。RunWorkerCompletedまたInvoke、UIスレッドのメソッドを使用して更新します。WinXP32ビットおよび64ビットOSではすべてが正常に機能しているようです。WinVistaおよびWin7（32ビットおよび64ビット）では、Invokeメソッドを使用してUIを更新しているときに、アプリケーションがランダムにハングします。
Invoke異なるWinOSでの変更の動作はありますか？スレッドからUIを更新する他の方法は何Invokeですか？
ありがとう
何が問題になっているのかはわかりませんがSystem.Windows.Forms.Timer、GUIを定期的に更新する実行をいつでも実行できます。いくつかのメンバー変数を使用して、必要に応じてロック内でスレッド間で生データを渡します。Invoke最も洗練されたソリューションではありませんが、メインスレッドのバックグラウンドスレッドに依存するのではなく、スレッドがこのように独立しているため、何がぶら下がっているのかについて異なる視点が得られる可能性があります。
Invokeの動作は異なるWinOSで変更されますか？
いいえ、すべきではありません。ただし、スレッドの問題は、非常に予測できない方法で発生する可能性があります。不明な問題がある可能性があります。
Invoke以外のスレッドからUIを更新する他の方法は何ですか？
特に単純な進行状況情報をUIスレッドに報告しようとする場合はInvoke、またはを使いすぎます。BeginInvoke主題に関連する私の答えのいくつかを検索すると、私が常にこのアプローチをリッピングしていることがわかります。そして、この手法を使用することには多くの欠点があるため、正当な理由があります。このメカニズムを、イベントBackgroundWorkerを通じてUIを更新するためだけに使用するのは残念です。ProgressChanged
別の方法の1つは、ワーカースレッドに進行状況情報を共有変数に公開させ、UIスレッドにタイマーを介して定期的にポーリングさせることです。これが、マーシャリング手法に対するこのアプローチを正当化する上での私の通常の論点のいくつかです。
InvokeとBeginInvoke高価な操作です。ISynchronizeInvokeます。Invoke。Dispatcher.Priority列挙型をパラメーターとして受け取るInvoke（）またはBeginInvoke（）オーバーロードのいずれかを使用してみることができます。「背景」などのパラメータを選択すると、アプリケーションがまだ応答していることがわかります。唯一の問題は、キューを増やすことなく、受信データを適切な速度で処理していることを確認することです。
もう1つのオプションは、マルチスレッドを完全に廃止することです。長時間実行する操作をチャンクに分割できる場合は、GUIスレッドで実行し、GUIApplication.DoEvents()を更新するときに使用します。
GUIを更新するだけでなく、ユーザー入力への応答やタイマーの開始などを開始できるため、このメソッドの使用は嫌いでしたが、最終的には、GUIが実行を開始できるバックグラウンドスレッドを使用するよりも安全です。いつでも何でも。したがって、おそらく、電話をかけるたびApplication.DoEvents()に、確認する必要があります_canceled。（私は最終的に、このメソッドの使用よりも線形実行順序の保証がなくなるため、このメソッドの存在を嫌うことにしました）。
もちろん、この方法ではマルチコアのサポートが失われるため、多数のバックグラウンド操作を同時に実行しようとすると、パフォーマンスに影響します。